On Sun, Jan 06, 2002 at 11:13:18PM -0600, Ben Combee wrote:
> A quick note: In CodeWarrior, 'abcd' always considers 'a' to be the
> high byte of the UInt32. The C++ parser basically sees this as a
> base-256 number
In my opinion, 'abcd' is a portability nightmare.
Its value is implementation-defined (C99 6.4.4.4/10) [1]. While
CodeWarrior may choose to define it as "always as if big-endian", it's
unreasonable to expect other compilers to make the same decision.
One user's expectation that '\x01\x02\x03\x04' == 0x01020304 is just
as reasonable as another's expectation that the bytes represented by
'\x01\x02\x03\x04' be the same as the first four represented by
"\x01\x02\x03\x04". But they cannot both be satisfied on a
non-big-endian architecture.
It's fine as long as Palm OS programmers are always writing to a
big-endian architecture, whether native m68k or emulated.
But if and when Palm OS programmers are writing native little-endian
ARM code, 'abcd' is unlikely to have the same value with all compilers
for that platform. At that time, I hope the use of multi-character
char constants will be retired in favour of something like a
MakeID('a','b','c','d') macro whose value would be portable amongst
compilers on that platform.
And if and when Palm OS programmers are trying to write code that is
portable between native m68k and native little-endian ARM, I suspect
that the best thing to do would be to make that macro's value be
portably the same as the first four bytes of "abcd".
Then they would compare equal without conversions on both platforms. I
suspect most people think of these things as legible text tokens such as
'MWDB' rather than numeric values, which motivates this choice.
John
[1] Of course, because we need these things to be longs instead of ints,
we're already beyond the Standard.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
