Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!xn.ll.mit.edu!hsdndev!cmcl2!phri!marob!daveh
From: daveh@marob.uucp (Dave Hammond)
Newsgroups: comp.lang.c
Subject: 0xFF != '\xFF' ???
Message-ID: <28021710.633E@marob.uucp>
Date: 9 Apr 91 19:33:36 GMT
Organization: ESCC, New York City
Lines: 40

[ this is a repost (I'm not sure if the distribution was correct on
 the first article) -- apologies if this is a duplicate article ]

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?  Or must I
expect this result from all C compilers?


/* c1.c */
main()
{
	int a = '\xFF';
	printf("a=%o\n",a);
}

/* c2.c */
main()
{
	int a = 0xFF;
	printf("a=%o\n",a);
}


output from diff c1.s c2.s:
4c4
< 	TITLE	$c1
---
> 	TITLE	$c2
33c33
< 	mov  	DWORD PTR [ebp-4], -1
---
> 	mov  	DWORD PTR [ebp-4], 255

--
Dave Hammond
daveh@marob.uucp
uunet!rutgers!phri!marob!daveh