0xFF != '\xFF' ?
Stephen Clamage
steve at taumet.com
Thu Apr 11 01:10:22 AEST 1991
grogers at convex.com (Geoffrey Rogers) writes:
|In article <28007837.35A9 at marob.uucp> daveh at marob.uucp (Dave Hammond) writes:
|>.... Is this because the '\nnn' token being seen as a char
|>value and chars are signed on the machines I tested on?
|Yes, this is correct. This is because char's can be either signed or
|unsigned. On the machines you mention, char is signed.
|>Or must I expect this result from all C compilers?
|No.
Le me also point out that you must be careful of code which depends on
whether the default char type is signed or unsigned; sooner or later
it will be ported to an environment where it will no longer work.
When possible, use explicit declarations of 'signed char' or 'unsigned
char'. (Unfortunately, not all compilers accept the 'signed' keyword.)
In the posted example, you could do something like:
int i = (unsigned char) '\xFF';
although it is unclear to me why this is better than using a non-char value:
int i = 0xFF;
--
Steve Clamage, TauMetric Corp, steve at taumet.com
More information about the Comp.lang.c
mailing list