Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!network!ucsd!orion.cf.uci.edu!uci-ics!zardoz!ccicpg!cci632!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs!rutgers!mcnc!spl
From: spl@mcnc.org (Steve Lamont)
Newsgroups: comp.lang.c
Subject: Re: What's a C expert?
Message-ID: <4722@alvin.mcnc.org>
Date: 22 Jul 89 14:03:26 GMT
References: <12214@well.UUCP> <6057@microsoft.UUCP>
Reply-To: spl@mcnc.org.UUCP (Steve Lamont)
Distribution: all
Organization: Microelectronics Center of NC; RTP, NC
Lines: 33

In article <6057@microsoft.UUCP> paulc@microsoft.UUCP (Paul Canniff 2/1011) writes:
>In article <12214@well.UUCP> tmh@well.UUCP (Todd M. Hoff) writes:
>>           What do you need to know to be an expert C programmer?
> [other "qualifications" deleted]
>                          ... can tell why the following code
>prints "false" (on 8-bit char systems).
>
>	char x = 0xff;
>
>	if (x != 0xff)
>		printf("FALSE\n");

The answer I assume you are looking for is that in the if-statement, the
value of x is expanded to an int and, since it is declared char rather
than unsigned char, the sign bit (high order) bit is propagated, making
x == -1 decimal.  This clearly differs from 0xff, which is, of course 255,
decimal.

However, when I tried this on my IRIS 4D to confirm my theory, I got the
"wrong" answer.  In other words, it did not print FALSE when run.  My
assumption is that the C compiler is not propagating the sign when
promoting x to an int in the if-statment.  (I don't read MIPS assembly
code well enough to verify this)

Is the Silly Graphics compiler broken, or is the behavior in the above
code simply unpredictable?  C "experts," what say you?

				(not an "expert", I just found the hat)
-- 
							spl
Steve Lamont, sciViGuy			EMail:	spl@ncsc.org
North Carolina Supercomputing Center	Phone: (919) 248-1120
Box 12732/RTP, NC 27709