Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c
Subject: Re: 0xFF != '\xFF' ?
Message-ID: <664@taumet.com>
Date: 10 Apr 91 15:10:22 GMT
References: <28007837.35A9@marob.uucp> <1991Apr10.033910.15537@convex.com>
Organization: Taumetric Corporation, San Diego
Lines: 27

grogers@convex.com (Geoffrey Rogers) writes:

|In article <28007837.35A9@marob.uucp> daveh@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@taumet.com