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: Sun, 15 Jan 2006 17:51:53 -0800
On Jan 15, 2006, at 12:04 AM, Markus Hitter wrote:
Am 14.01.2006 um 09:27 schrieb Steve Christensen:
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'
[...] and on a little-endian Intel-based computer,
typeCreator.longs[0] == 'LPPA'
typeCreator.longs[1] == 'KWMF'
In short: 'A' 'P' 'P' 'L' != 'APPL'.
Well, on a little-endian processor, yes.
That's really odd. In fact I didn't believe it until I asked a
friend to run a small test app on their Intel-based Linux machine.
I'd have sweared endianess doesn't affect how bytes are sorted, but
only how they are interpreted. I was wrong :-}
It shouldn't seem that odd; it simply comes down to how a particular
processor accesses memory. The Intel processors expect longs (for
example) in little-endian order in memory. In the PkgInfo case, the
data was written to disk in big-endian order and will be read into
memory in big-endian order, regardless of the processor. When the
Intel processor then reads one of the longs ('APPL'), the bytes are
interpreted incorrectly ('LPPA') unless you first flip them using
CFSwapInt32BigToHost.
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