Re: Endian-ness of four-char constants (Was: Endian-ness of "PkgInfo" file)
Re: Endian-ness of four-char constants (Was: Endian-ness of "PkgInfo" file)
- Subject: Re: Endian-ness of four-char constants (Was: Endian-ness of "PkgInfo" file)
- From: Steve Christensen <email@hidden>
- Date: Sat, 14 Jan 2006 00:27:50 -0800
On Jan 13, 2006, at 4:04 PM, Markus Hitter wrote:
Am 13.01.2006 um 22:17 schrieb Kirk Kerekes:
This is an 8-byte file consisting of a Mac-style Type and Creator.
Can anyone provide an authoritative answer as to how this is
stored on OS-X/intel?
Little-endian? (Host)
Big-endian? (PPC-style)
There are so many questions of this type, here and elsewhere.
They are four single bytes, representing four characters. If you
swap bytes there, you change the sequence of those characters, but
not their value.
Even if you interpret them as an integer number, endianess doesn't
matter as long as you don't do calculations with them. ('APPL' +
'FMWK') * 3 anybody?
Could somebody please try to explain why people think four-
character constants are subject for endianess issues?
The constants themselves are not a subject for endian issues since
they are always represented correctly in memory for the current
architecture. The endian issue comes up when you compare them against
data read from disk, or when you write constants out to disk, if the
data on disk is not represented in the native endianness for the
current architecture.
In the case mentioned, when you read the eight bytes in the PkgInfo
file into memory, they're going to be read in big-endian order
because that's how they're stored on disk. Any operations that treat
them as long[2] instead of char[8] need to ensure that the two longs
have been flipped appropriately so you get the same results for all
architectures.
As an example, suppose you did something like:
union
{
char bytes[8];
unsigned long longs[2];
} typeCreator;
readFromPkgInfo(&typeCreator.bytes, 8);
The typeCreator.bytes would then contain
'A' 'P' 'P' 'L' 'F' 'M' 'W' 'K'
Assuming no byte flipping was done, on a big-endian PowerPC-based
computer,
typeCreator.longs[0] == 'APPL'
typeCreator.longs[1] == 'FMWK'
and on a little-endian Intel-based computer,
typeCreator.longs[0] == 'LPPA'
typeCreator.longs[1] == 'KWMF'
The four-byte constants still have their expected values, but the
values read from disk are "wrong" because they still have a non-
native endianness. So on the Intel computer, you couldn't correctly
compare (typeCreator.longs[0] == 'APPL').
steve
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden