Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!gitpyr!roy
From: roy@gitpyr.UUCP (Roy Mongiovi)
Newsgroups: net.lang.c,net.micro,net.micro.pc
Subject: Re: weird C behavior
Message-ID: <1579@gitpyr.UUCP>
Date: Sat, 22-Mar-86 03:17:31 EST
Article-I.D.: gitpyr.1579
Posted: Sat Mar 22 03:17:31 1986
Date-Received: Sat, 22-Mar-86 22:42:44 EST
References: <557@utastro.UUCP>
Organization: Georgia Institute of Technology, Atlanta
Lines: 22
Keywords: strange, opaque, odd
Xref: watmath net.lang.c:8220 net.micro:14086 net.micro.pc:7495
Summary: seems pretty clear to me

In article <557@utastro.UUCP>, nather@utastro.UUCP (Ed Nather) writes:
> Equality NOT found: i = -28672, BIG = -28672

Ok.  The #defined constant is greater than 32767, so it's a long on a
16 bit machine.  Top 16 bits are zero, bottom are 0x9000.  It gets
assigned into an SIGNED integer, so that gets the bottom 16 bits.
Then to perform the comparison, C promotes the int to a long, and
since it's signed that extends the sign bit.  One value now has
the top 16 bits zero, the other has 0xFFFF.  Unfortunately, the
program ignores the fact that the constant is a long, and printf's
it through a %d.  Since words and bytes are stored in least significant,
most significant order in memory, the address passed to printf for both
variables is that of the bottom 16 bits, which are equal.  Therefore
the printed output seems to contradict the comparison.

The real question is:  who made the mistake?  The compiler by assuming
the constant is a long, or the programmer by printing with a %d?  Maybe
you ought to have to say L to get a long constant....
-- 
Roy J. Mongiovi.	Office of Computing Services.		User Services.
Georgia Institute of Technology.	Atlanta GA  30332.	(404) 894-6163
 ...!{akgua, allegra, amd, hplabs, ihnp4, masscomp, ut-ngp}!gatech!gitpyr!roy