"Roger Browne" <[EMAIL PROTECTED]> wrote:
If you do tweak the signature for the packfile format, I suggest you
take a leaf out of the PNG specification and ensure that the signature
will robustly detect common errors such as byte order transpositions,
CRLF-to-newline mappings (e.g. when binary files are FTPd using ASCII
mode), etc.
See section 12.11 of the PNG specification:
http://www.faqs.org/rfcs/rfc2083.html
Interesting, thanks - they make some good suggestions there. Our current
magic number is "13155a1" - I'm unsure of the rationale behind it, but there
may be a reason. If we're going to change the packfile format, we may as
well make sure we're squeezing whatever use we can out of our magic number.
"Mark A. Biggar" <[EMAIL PROTECTED]> wrote:
Joshua Hoblitt wrote:
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
When I talked about doing something endian-independent, I meant something
along the lines of store a sequence of, say, 4 bytes that will have certain
values. Forget reading the 4 bytes as an int at all, read it as a char[4]
and check each element is what it should be. Makes adding support to "file"
easy enough, and is my preferred solution.
d) use a magic number that can also be used as the byte order indicator.
Clever, though not sure it helps with writing something to independently
identify a Parrot packfile, if it can be one of a number of things (though I
guess in this case, one of only two things - unless there's some insane
ordering scheme I've not heard of).
Before rushing into fixing this, it's worth pondering why the designer of
the packfile format might have chosen to have the magic number in native
endian format. All I came up with was that it was a good way of making sure
we really had transformed the input to the correct byte ordering. If we
didn't find out at the magic, we probably wouldn't until we got to byte 24 -
the directory format.
So, now we have two design decisions:-
1) How to store the magic "number"
2) What the magic "number" should be
Jonathan
