Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!netcom!allanh
From: allanh@netcom.UUCP (Allan N. Hessenflow)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C 3.1 vs 3.0
Summary: the other number is cast
Message-ID: <11924@netcom.UUCP>
Date: 10 May 90 00:23:22 GMT
References: <2597@crash.cts.com>
Organization: NetCom- The Bay Area's Public Access Unix System {408 249-0290 guest}
Lines: 23

In article <2597@crash.cts.com>, jholt@pro-sol.cts.com (joe holt) writes:
> In-Reply-To: message from allanh@netcom.UUCP
> 
> The way I read K&R, it sounds like MPW 3.0 did things the right way.  ANSI C
> says that if a hexadecimal constant is suffixed with 'l' or 'L', then its type
> is long int or unsigned long int.  The compiler is supposed to try to fit the
> constant into long int first, then unsigned long int if it doesn't fit.  The
> constant 0xF0000000L would not fit into a long int, and so its type becomes
> unsigned long int (it is legal to have the constant -0x7FFFFFFF, for example).

I believe both versions of the C compiler interpreted the constant as an
unsigned long.  It's what they did with the long variable in the expression
that differs.  In v3.0, it apparently cast it as an unsigned.  In v3.1, it
didn't and so the comparison 'count<0xf0000000L' was always true.  I haven't
looked at the generated code, but I assume the v3.1 compiler figured out
that the test would be always true.  I don't see any other way it could
have generated a test for that expression since it doesn't have any ints
larger than 32 bits it could have cast them to.  Actually, it doesn't seem
very likely it would do that; I think I'll go look at the code it generated.


-- 
Allan N. Hessenflow   {apple|claris}!netcom!allanh    allanh@netcom.uucp