shared-mime-info endianness issue

[David Faure]

On jeudi 29 décembre 2016 17:26:12 CET Bastien Nocera wrote:
> 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.

We agree, but that means there's also a bug in the reference implementation, 
because it should NOT match test.jks, and it does.

> 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.

Sure. But the fact that it passes on a little endian machine given the broken 
definition, looks to me like a bug in update-mime-database or in xdgmime.
Any chance you can look into it ? I'm not great at reading glib code...

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

OK will do (I also have push access, but reviews are good)

Thanks,

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