shared-mime-info endianness issue
faure at kde.org
Mon Dec 26 12:35:33 UTC 2016
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
More information about the xdg