Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!convex!grogers
From: grogers@convex.com (Geoffrey Rogers)
Newsgroups: comp.lang.c
Subject: Re: 0xFF != '\xFF' ?
Message-ID: <1991Apr10.033910.15537@convex.com>
Date: 10 Apr 91 03:39:10 GMT
References: <28007837.35A9@marob.uucp>
Sender: usenet@convex.com (news access account)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 19
Nntp-Posting-Host: mozart.convex.com

In article <28007837.35A9@marob.uucp> daveh@marob.uucp (Dave Hammond) writes:
>In the following code examples, the '\nnn' representation causes the
>compiler to sign-extend 8 bit values, causing comparisons to fail (255
>!= -1).  This occurred on every machine I tested (Generic 386, Altos
>386, DEC uVax).  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.

+------------------------------------+---------------------------------+
| Geoffrey C. Rogers   		     | "Whose brain did you get?"      |
| grogers@convex.com                 | "Abbie Normal!"                 |
| {sun,uunet,uiucdcs}!convex!grogers |                                 |
+------------------------------------+---------------------------------+