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