shared-mime-info endianness issue

[Bastien Nocera]

On Mon, 2016-12-26 at 13:35 +0100, David Faure wrote:
> The magic for application/x-java-keystore says
> <match type="host32" value="0xfeedfeed" offset="0"/>
> 
> And the test file test.jks starts with 0xFE, 0xED, 0xFE, 0xED.
> On a little-endian machine this leads to a value of 0xedfeedfe
> when read as a single 32-bit value.
> 
> So this does not match. Am I missing something?
> 
> I found this with an implementation which does not go through
> mime.cache but 
> reads directly from the XML, so the fact that xdgmime works on this
> file might 
> indicate a bug related to the mime.cache intermediary?
> 
> http://mindprod.com/jgloss/cacerts.html says "The first four
> signature bytes of 
> a Sun cacerts file in hex are FEEDFEED." so I wonder if this rule
> should say 
> big32 instead of host32. With big32, both the s-m-i testsuite and my 
> implementation (which uses the same testsuite) pass.
> 
> Everything else passes, which makes me wonder if this is the only
> "host" match 
> actually used by the test suite ;)
> Actually, if it's not, then I have to assume the test suite is known
> broken on 
> big-endian machines, given that any "host" match would fail there,
> unless we 
> put two versions of the file in the testsuite (one generated for
> little-endian 
> machines and one generated for big-endian machines). But apparently
> this isn't 
> needed yet, if I'm right that the java keystore magic should say
> big32.

This looks like a straight up bug in the definition.

Given that the test suite only runs from git checkouts, and that
developers with big endian machines are pretty thin on the ground, this
likely never got tested.

Feel free to file a bug and attach a patch for those wrong definitions.

Cheers