Re: gcc bug/quirk with left shifts on i386 family.

[Toshi Morita <tm2 at best dot com>]

> Toshi Morita wrote:
> > > I'm not sure if this is a real bug or one of those gray 'implementation
> > > defined' areas of the language, but it looks rather strange:
> > 
> > (stuff deleted)
> > 
> > > 117$ ./shift
> > > 1U << 32 = 0
> > > thirtytwo = 32
> > > 1U << thirtytwo = 1
> > 
> > If you read the back of your 2nd edition K&R where the ANSI C standard
> > is printed in its entirety, you will notice that this is implementation-
> > dependent.
> > 
> > You may want to consult the ANSI C standard (ANS X3.159-1989) before
> > reporting any further GCC anomolies.
> 
> I realize it is implementation dependent, but the complaint is:
> 
> int foo = 32;
> 1 << 32 = 0
> 1 << foo = 1
> 
> It should be consistant.
> 
> Cheers,
> -Peter
> --
> Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
> "All of this is for nothing if we don't go to the stars" - JMS/B5

Let's examine the semantics of "undefined operation".

This means the operation "1 << 32" where sizeof(int) == 4 could return 
any number.

If your compiler generated a call to rand() to return 1 << 32, then this
would be perfectly valid behavior because the operation is undefined.

If you compiled code with this compiler which checked int foo = 32;
if ((1 << foo) == (1 << foo)) { } then this would usually return false
because you would be comparing two random values which would usually
not be equal.

There is no semantic implication that an undefined operation returns
a consistent result, and hopefully this example has enlightened you.

Toshi