shared-mime-info endianness issue

[David Faure]

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.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5