Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!etive!gja
From: gja@etive.ed.ac.uk (A Cunningham)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC 3 bug with hex constant handling?
Keywords: Lightspeed C
Message-ID: <2323@etive.ed.ac.uk>
Date: 12 Jun 89 13:07:19 GMT
References: <861@key.COM>
Reply-To: gja@etive.ed.ac.uk (A Cunningham)
Organization: Edinburgh University Unix Anarchists
Lines: 25

In article <861@key.COM> perry@arkon.key.COM (Perry The Cynic) writes:
>Consider the following code fragment for Lightspeed (aka THINK) C 3.0.2:
>	long a, b;
>	a = b & ~1;
>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)

	According to K&R page 35 the 0x implies an int type. If ints are 32
bits in this implementation then ~0x1 should be FFFE.

>BTW, using "0x1L" works, as does (of course) "1L".

	This makes the constant long which in a 64 bit implementation is
0xFFFFFFFE. I think however that the size of an int is a machine dependant
thing. 
		Tony
"I think of Sarah. The rest is easy."

Eat
this 
and 
die,
inews