From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Error trying to Shift Longs & LongLong
Date:	23 Apr 2003 17:45:39 GMT
Organization:	Aachen University of Technology (RWTH)
Lines:	35
Message-ID:	<b86jg3$149$1@nets3.rz.RWTH-Aachen.DE>
References:	<l4jdavgfk12obr35dfrs0oqtahdthcfhcu AT 4ax DOT com>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 1051119939 1161 137.226.32.75 (23 Apr 2003 17:45:39 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	23 Apr 2003 17:45:39 GMT
Originator:	broeker@
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Radical wrote:

> The program below works 100% correctly in Borland,

No, it doesn't, because there is no such thing as a "correct"
behaviour for the code you've written.

> why should shifting by a (-1) create such an unsual value?

Because the result from such an operation is not defined by the
language specification --- it causes what the C standard calls
"undefined behaviour".  Returning the phase of the moon expressed in
seconds since the last full moon would be an equally correct result,
in this case.

> Shouldn't shifting by "all" bits give Zero ?

Not necessarily.  This also causes undefined behaviour.

To quote the authorities:

       [#3] The integer promotions are performed  on  each  of  the
       operands.   The  type  of the result is that of the promoted
       left operand.  If the value of the right operand is negative
       or  is  greater  than  or equal to the width of the promoted
       left operand, the behavior is undefined.

> Why is the "sign-bit" apparently being shifted into things?

Because it's there.  If you want portable and predictable results in
shift operations, you *have* to use unsigned operands.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -