On Wed, Sep 21, 2005 at 11:44:17AM +0100, Jonathan Worthington wrote: > "Joshua Hoblitt via RT" <[EMAIL PROTECTED]> wrote: > >>[jhoblitt - Mon Sep 19 22:28:00 2005]: > >> > >>> [EMAIL PROTECTED] - Sun Sep 22 07:13:56 2002]: > >>> > >>> If you're going to check the magic after the wordsize and bytecode, you > >>> might as well get rid of it altogether. > >>> > The only way we can *really* fix this is by not storing the magic number in > native endian form. At the moment we have to read the byteorder before the > magic number so we can transform it into native form. > > Of course, there's nothing to prevent us putting in a "hack" that says "is > this magic number OK in any of the byte orderings we support".
I was looking at adding pbc support to 'file' this morning and the only way to handle that would be to test for both byte orderings of the magic number. > This is a design decision - Chip (or leo), which road should we go down? > Change the packfile format, or code around the current way we do it? I agree. Some possible options are: a) live with it b) change the magic number to be two identical bytes so the byte ordering doesn't matter c) shrink the magic number to be a single byte > >>The issue seems to be related to the jit core being in use. I can't > >>recreate it on amd64 (no jit) > I can't see any way it could be something to do with the JIT core, or any > runcore. We haven't even entered one at the point the above error is given. Fair enough. I should have said it's related to the '-j' flag. > >Jonathan has volunteered to look into this. Thanks. > > > I'll do what I can. Your willingness to help is much appreciated. -J --
pgpGOkZfn2cxQ.pgp
Description: PGP signature
