Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!spam!lippin
From: lippin@spam.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC 3 bug with hex constant handling?
Message-ID: <25427@agate.BERKELEY.EDU>
Date: 13 Jun 89 01:06:42 GMT
References: <861@key.COM> <16783@bellcore.bellcore.com>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 18

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.

This is the correct behaviour if hexadecimal constants are taken to be
unsigned -- the unsigned value would not be sign extended in that
case.  Since I don't have a book of C here, I can't tell you whether
hex constants are signed or not, although unsigned seems plausible.
Perhaps someone out there has the reference handy?

					--Tom Lippincott
					  lippin@math.berkeley.edu

    "Don't be silly.  Of course you're a number, just like everyone else"
					--John Chiapetta