On Jan 26, 2008 8:41 AM, Bill Royds <email@hidden> wrote:
>
> On 26-Jan-08, at 24:47 , Charlie Dickman wrote:
>
> > In moving projects from Xcode 2 on Tiger (G4) to Xcode 3 on Leopard
> > (Intel) I have found two cases of code (Objective C) that breaks in
> > Xcode 3 on Leopard (Intel) that works perfectly fine in Xcode 2 on
> > Tiger (G4)...
> >
> > unsigned u = '\1\0\0\0';
> > u >>= 8;
> >
> > results in u equal to '\0\1\0\0' in Xcode 2 on Tiger (G4) but
> > results in '\1\1\0\0' in Xcode 3 on Leopard (Intel).
> >
>
> Both are correct. G4 is a big-endian computer and Intel is a little-
> Endian. You have the result required by the C standard for both.
> Shifts are architecture dependent.
No, shifts on unsigned types are *not* architecture dependent. The C
standard guarantees that bit-shifts operate on *values* not
*representations*.
As long as u is an unsigned integer type, or it is a signed integer
type with a positive value
(u >>= 8) is always equivalent to (u /= 256), regardless of the architecture.
What *is* implementation defined, however, is the result of having
more than one character within single quotes. However, if you accept
the common Macintosh convention of allowing four-char-codes to be
defined with single quotes, you will find that, on both architectures,
'\1\0\0\0' == 0x01000000:
[ccox@clarkco:~]% cat test.c
#include <stdio.h>
int main() {
unsigned u = '\1\0\0\0';
printf ("'\\1\\0\\0\\0' == 0x%.8X\n", u);
printf ("'\\1\\0\\0\\0' >> 8 == 0x%.8X\n", u >> 8);
return 0;
}
[ccox@clarkco:~]% cc -arch i386 test.c && ./a.out
'\1\0\0\0' == 0x01000000
'\1\0\0\0' >> 8 == 0x00010000
[ccox@clarkco:~]% cc -arch ppc test.c && ./a.out
'\1\0\0\0' == 0x01000000
'\1\0\0\0' >> 8 == 0x00010000
--
Clark S. Cox III
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
This email sent to email@hidden
