0xFF != '\xFF' ???

Dave Hammond daveh at marob.uucp
Wed Apr 10 05:33:36 AEST 1991


[ 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 at marob.uucp
uunet!rutgers!phri!marob!daveh



More information about the Comp.lang.c mailing list