<div dir="ltr">Thanks, David, that all makes sense of me. I'll ensure that the next version of PyXDG applies the mask to both values, until we can be confident that it will see the updated version of the magic database.<br>

<br>Thomas<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 April 2013 17:42, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tuesday 19 March 2013 13:57:04 Thomas Kluyver wrote:<br>
> On 19 March 2013 13:28, David Faure <<a href="mailto:faure@kde.org">faure@kde.org</a>> wrote:<br>
> > The other would be to write code that detects the cases where the database<br>
> > has<br>
> > values such that  (value & mask) != value, and fixing the database to<br>
> > specify<br>
> > (value & mask) as value from now on. This would allow implementations to<br>
> > avoid<br>
> > having to mask the value at runtime, which would lead to a minor speedup<br>
> > (and<br>
> > to the spec being correct after all).<br>
> > Such code would be easy to write, as part of any of the existing<br>
> > implementations, I would think.<br>
><br>
> Yes, I think that sounds reasonable, although of course implementations<br>
> will need to support the existing data for some time, even if newer<br>
> versions of shared-mime-info fix that.<br>
<br>
</div>I don't see that point. I'm talking about fixing the shared-mime-info data to<br>
have more useful expected values, this won't break existing implementations at<br>
all.<br>
<br>
What I meant by "Such code" and "the existing implementations" was to add a<br>
check in one implementation and use that to detect the weird expected values.<br>
But you've already done that apparently, by manual inspection.<br>
<br>
You're right though, removing the masking of the value in the implementations<br>
cannot be done for quite some time, even if we adjust the data today.<br>
Still, at some point this will be useful :)<br>
<div class="im"><br>
> The downside is that<br>
> update-mime-database is written in C, and as I found yesterday, I'm lousy<br>
> at fixing C code. (Aside: this is an occasionally used script where<br>
> performance isn't that important - would it make sense to write it in<br>
> Python rather than C?)<br>
<br>
</div>Not my code, I can't comment on that. But IMHO let's not start a language<br>
flamewar. It's there and it works.<br>
<div class="im"><br>
> I've just inspected the values I have. There aren't many rules using masks<br>
> at all. Of those that are, 5 need the mask applied, in all cases because<br>
> they use a placeholder character where the mask has a null byte.<br>
><br>
> - application/x-core, application/x-sharedlib and<br>
> application/vnd.adobe.photoshop use spaces<br>
> - image/bmp uses lowercase 'x'<br>
> - application/vnd.corel-draw uses an uppercase 'X'<br>
<br>
</div>Ah, so this leads to more readable magic than using '\000' in the value field.<br>
But indeed, update-mime-database could take care of sanitizing the value in<br>
the generated output.<br>
<br>
OK, done for int values too, which caught one more case:<br>
  <mime-type type="image/x-sigma-x3f"><br>
        <match value="0x00FF00FF" type="little32" offset="4"<br>
mask="0xFF00FF00"/><br>
I wonder if it's intended, i.e. the FF in the value field mean nothing...<br>
OK, <a href="http://www.photofo.com/downloads/x3f-raw-format.pdf" target="_blank">http://www.photofo.com/downloads/x3f-raw-format.pdf</a> says this is correct.<br>
The goal is to catch a version number like 0x00010003, for 1.3.<br>
<br>
And done for strings too (I'm not C/glib programmer either, I'm rather a<br>
C++/Qt guy, so this should be reviewed by glib people) ;)<br>
<br>
Attached is the diff (after hex-dumping) of the generated magic files.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE, in particular KDE Frameworks 5<br>
</div></div></blockquote></div><br></div>