Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!paperboy!hsdndev!cmcl2!phri!marob!daveh
From: daveh@marob.uucp (Dave Hammond)
Newsgroups: comp.lang.c
Subject: 0xFF != '\xFF' ?
Message-ID: <28007837.35A9@marob.uucp>
Date: 8 Apr 91 14:03:34 GMT
Organization: ESCC, New York City
Lines: 37

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