Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!cadnetix.COM!cadnetix!pem
From: pem@cadnetix.COM (Paul Meyer)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC 3 bug with hex constant handling?
Summary: hex === unsigned
Keywords: Lightspeed C
Message-ID: <8405@cadnetix.COM>
Date: 12 Jun 89 18:03:45 GMT
References: <861@key.COM>
Sender: news@cadnetix.COM
Reply-To: pem@cadnetix.COM (Paul Meyer)
Organization: Cadnetix Corp.,  Boulder, CO
Lines: 33

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;
...[vs.]...
>	a = b & ~0x1;
...
>Question: is this a bug, or am I overlooking something? I think that the
>decimal and hex forms of a constant are semantically equivalent.
...
>BTW, using "0x1L" works, as does (of course) "1L".

	Using the hexadecimal form implies an unsigned int, while
using decimal implies a signed int.  (I think this is even K&R (my K&R
is at home), and it's certainly a useful and reasonable convention.)
So when the int value "~1" gets extended to a long, if it is signed it
sign-extends, but if it's not it doesn't.
	signed:		1 => 0x0001
		 	~1 => 0xfffe
		 	(long) ~1 => 0xfffffffe
	unsigned: 	0x1 => 0x0001
			~0x1 => 0xfffe
			(unsigned long) ~0x1 => 0x0000fffe
			(long) (unsigned long) ~0x1 => 0x0000fffe
kapeesh?

	In any case, you're better off using the explicitly long
constant anyway.  Then the compiler isn't resolving any casts for you,
it's just putting in exactly what you tell it.
Paul Meyer                      pem@cadnetix.COM
Daisy/Cadnetix Inc.		{uunet,boulder}!cadnetix!pem
5775 Flatirons Pkwy.            GEnie P.MEYER
Boulder, CO 80301               (303)444-8075x277