Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!wind!sdh
From: sdh@wind.bellcore.com (Stephen D Hawley)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC 3 bug with hex constant handling?
Keywords: Lightspeed C
Message-ID: <16783@bellcore.bellcore.com>
Date: 12 Jun 89 14:01:57 GMT
References: <861@key.COM>
Sender: news@bellcore.bellcore.com
Reply-To: sdh@wind.UUCP (Stephen D Hawley)
Organization: Bellcore, Morristown, NJ
Lines: 22

In article <861@key.COM> perry@arkon.key.COM (Perry The Cynic) writes:
>This clears the least significant bit of b. It works just fine. However,
>if I replace the "1" with its hex equivalent, i.e.
>	a = b & ~0x1;
>then the resulting code uses the constant 0x0000FFFE (rather than 0xFFFFFFFE)
>as operand to the "&" operator, resulting in less than satisfactory results.
>

From K&R:
"A sequence of digits preceded by 0x or 0X (digit zero) is taken to be a
hexadecimal integer.  ...  A decimal constant whose value exceeds the largest
unsigned machine integer is taken to be a long; an octal or hex constant which
exceeds the largest unsigned machine integer is likewise taken to be long."

This means that the constant is correct as an int, but section 7.8 claims that
& uses the usual arithmetic conversions.  In this case, it should be converted
to a long (section 6.6).

I would say this is a bug.

Steve Hawley
sdh@flash.bellcore.com