Re: potential endian-related problem?
Re: potential endian-related problem?
- Subject: Re: potential endian-related problem?
- From: Nicko van Someren <email@hidden>
- Date: Fri, 8 Jul 2005 11:55:40 +0100
On 8 Jul 2005, at 11:32, Chase wrote:
on my ppc-mac, this code:
int i;
for (i = 1; i; i<<=1) {
printf("%d\n", i);
}
... produces the following output:
1
2
...
1073741824
-2147483648
this, to me, looks like it's going to need an adjustment to work
the same on intel.
On the contrary. The << and >> operators are defined in the C
specification as working this way and the behaviour is irrespective
of the byte ordering on the integer representation.
can someone point out if this will indeed need to be fixed to work
on intel and, if so, what change will need to be made?
For that sort of code you will be fine. Where you will have problems
is with code like:
unsigned int x = 0xDEADBEEF;
unsigned short *sp = (unsigned short *) &x;
unsigned char *cp = (unsigned char *) &x;
printf("%X %X %X\n", x, *sp, *cp);
On processors which put the most significant bytes first (like a PPC)
this comes out as:
DEADBEEF DEAD DE
whereas on processors which put the least significant byte first
(like x86) this comes out as:
DEADBEEF BEEF EF
I hope this helps.
Nicko
_______________________________________________
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