shared-mime-info endianness issue

[Bastien Nocera]

On Thu, 2016-12-29 at 17:44 +0100, David Faure wrote:
> 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...

I never tried to understand this code, or the binary cache format,
Matthias is the maintainer of it as far as I'm concerned.

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

I usually review patches :)