Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Inconsistent behaviour for (1 << 32)

Reply
Thread Tools

Inconsistent behaviour for (1 << 32)

 
 
Keith Thompson
Guest
Posts: n/a
 
      10-20-2007
Daniel Kraft <(E-Mail Removed)> writes:
> I did encounter a strange problem in my C program, and traced it down;
> it looks like I get different results for bit left shifts when the bit
> count is a constant or a funtion-return value.
>
> When doing (1 << 32) for a 32-bit-unsigned I expect to get 0; can I
> assume this, or is this something I should never do?

[...]

It's something you should never do. Quoting the standard,

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.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
christian.bau
Guest
Posts: n/a
 
      10-20-2007
A left or right shift of a value x by n invokes undefined behaviour if
n is negative, or greater than or equal to the number of bits in x.
Note that this includes the case "equal". So for 32 bit values, x <<
32 invokes undefined behaviour.

Don't do it.



 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      10-20-2007
Daniel Kraft said:

> Hi,
>
> I did encounter a strange problem in my C program, and traced it down;
> it looks like I get different results for bit left shifts when the bit
> count is a constant or a funtion-return value.
>
> When doing (1 << 32) for a 32-bit-unsigned I expect to get 0;


The behaviour is undefined if the number of bits by which you are shifting
is >= the number of bits in the object.

3.3.7 of C89 says: "If the value of the right operand is negative or is
greater than or equal to the width in bits of the promoted left operand,
the behavior is undefined."

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Daniel Kraft
Guest
Posts: n/a
 
      10-20-2007
Hi,

I did encounter a strange problem in my C program, and traced it down;
it looks like I get different results for bit left shifts when the bit
count is a constant or a funtion-return value.

When doing (1 << 32) for a 32-bit-unsigned I expect to get 0; can I
assume this, or is this something I should never do? However, running
the attached code gives me two different outputs (1 0) when run, while I
expected it to print 0 0.

I use gcc 4.2.1 like this:
gcc -pedantic -std=c99 test.c -o test

When I turn on optimization, I get the expected results! Is this some
compiler problem or does my program trigger some undefined behaviour?

Thanks,
Daniel


#include <stdio.h>
#include <stdint.h>
#include <assert.h>

#define NUM_BITS ((unsigned short)(8*sizeof(unsigned)))

unsigned short getBits()
{
return NUM_BITS;
}

int main()
{
unsigned a=(1 << getBits());
unsigned b=(1 << NUM_BITS);
assert(NUM_BITS==getBits());
printf("%u %u\n", a, b);
return 0;
}
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      10-20-2007
"Daniel Kraft" <(E-Mail Removed)> a écrit dans le message de news:
ffchgo$4gh$(E-Mail Removed)...
> >> I did encounter a strange problem in my C program, and traced it down;
> >> it looks like I get different results for bit left shifts when the bit
> >> count is a constant or a funtion-return value.
> >>
> >> When doing (1 << 32) for a 32-bit-unsigned I expect to get 0;

> >
> > The behaviour is undefined if the number of bits by which you are

> shifting is >= the number of bits in the object.
>
> Ok, thank you!
>
> What I'm trying to do is this: I've got some unsigned type, and a
> function which returns a number of bits <= the number of usable bits of
> this type.
>
> I need to calculate (1 << getBits())-1, i.e., set the lower getBits() bits
> to one (which might be all ones if it is equal to the type's width, but it
> also might be only some less-significant-bits ones).
>
> Is there some other clever way to do this?


Use an array of unsigned ints with 33 elements.

unsigned int mask = mask_array[getBits()];

Or use a test:

unsigned n = getBits();
unsigned mask = (n < sizeof(unsigned) * CHAR_BIT) ? (1U << n) - 1 : -1U;

Ultimately, if you know that getBits() > 0 and no greater than the width of
the unsigned type, use this expression:

unsigned mask = ((1U << (getBits() - 1)) << 1) - 1;

or even:

unsigned mask = ~(-2U << (getBits() - 1));

or optimally:

unsigned mask = -1U >> (sizeof(unsigned) * CHAR_BIT - getBits());

--
Chqrlie.


 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      10-20-2007
"Daniel Kraft" <(E-Mail Removed)> a écrit dans le message de news:
ffcjh5$8s6$(E-Mail Removed)...
> Daniel Kraft wrote:
>> >> I did encounter a strange problem in my C program, and traced it

>> down;
>> >> it looks like I get different results for bit left shifts when the

>> bit
>> >> count is a constant or a funtion-return value.
>> >>
>> >> When doing (1 << 32) for a 32-bit-unsigned I expect to get 0;
>> >
>> > The behaviour is undefined if the number of bits by which you are

>> shifting is >= the number of bits in the object.
>>
>> Ok, thank you!
>>
>> What I'm trying to do is this: I've got some unsigned type, and a
>> function which returns a number of bits <= the number of usable bits of
>> this type.
>>
>> I need to calculate (1 << getBits())-1, i.e., set the lower getBits()
>> bits to one (which might be all ones if it is equal to the type's width,
>> but it also might be only some less-significant-bits ones).

>
> I think I found a solution:
>
> instead of (1 << getBits()) which might result in this undefined behaviour
> I do (2 << (getBits()-1)) (getBits() is never 0). This should be
> well-defined, right?


So you came up with one of my proposed solutions on your own

This one is well defined only upto 31, because 2 is an int, and behaviour on
overflow is implementation defined. Use (2U << (getBits()-1)) to fix this,
but look at my last proposal elsethread that requires fewer operations to
compute the mask itself.

--
Chqrlie.


 
Reply With Quote
 
Martin Wells
Guest
Posts: n/a
 
      10-20-2007
Daniel:

> instead of (1 << getBits()) which might result in this undefined
> behaviour I do (2 << (getBits()-1)) (getBits() is never 0). This should
> be well-defined, right?



Sounds good. Still don't know why you're shifting signed integer types
though.

Martin

 
Reply With Quote
 
Daniel Kraft
Guest
Posts: n/a
 
      10-20-2007
>> I did encounter a strange problem in my C program, and traced it down;
>> it looks like I get different results for bit left shifts when the bit
>> count is a constant or a funtion-return value.
>>
>> When doing (1 << 32) for a 32-bit-unsigned I expect to get 0;

>
> The behaviour is undefined if the number of bits by which you are

shifting is >= the number of bits in the object.

Ok, thank you!

What I'm trying to do is this: I've got some unsigned type, and a
function which returns a number of bits <= the number of usable bits of
this type.

I need to calculate (1 << getBits())-1, i.e., set the lower getBits()
bits to one (which might be all ones if it is equal to the type's width,
but it also might be only some less-significant-bits ones).

Is there some other clever way to do this?

Thanks,
Daniel

--
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress--so
please use good, old E-MAIL!
 
Reply With Quote
 
Daniel Kraft
Guest
Posts: n/a
 
      10-20-2007
Daniel Kraft wrote:
> >> I did encounter a strange problem in my C program, and traced it down;
> >> it looks like I get different results for bit left shifts when the bit
> >> count is a constant or a funtion-return value.
> >>
> >> When doing (1 << 32) for a 32-bit-unsigned I expect to get 0;

> >
> > The behaviour is undefined if the number of bits by which you are

> shifting is >= the number of bits in the object.
>
> Ok, thank you!
>
> What I'm trying to do is this: I've got some unsigned type, and a
> function which returns a number of bits <= the number of usable bits of
> this type.
>
> I need to calculate (1 << getBits())-1, i.e., set the lower getBits()
> bits to one (which might be all ones if it is equal to the type's width,
> but it also might be only some less-significant-bits ones).


I think I found a solution:

instead of (1 << getBits()) which might result in this undefined
behaviour I do (2 << (getBits()-1)) (getBits() is never 0). This should
be well-defined, right?

Cheers,
Daniel


--
Got two Dear-Daniel-Instant Messages
by MSN, associate ICQ with stress--so
please use good, old E-MAIL!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inconsistent float behaviour on "inf" - current state? =?iso-8859-15?Q?Peter_Kn=F6rrich?= Python 1 06-27-2006 04:16 PM
CSS inconsistent behaviour Ian Davies HTML 6 05-18-2006 07:20 AM
inconsistent behaviour of const_iterator and const_reverse_iterator Serengeti C++ 2 11-20-2005 01:50 PM
Inconsistent webservice behaviour MB ASP .Net Web Services 0 12-08-2004 08:58 PM
Inconsistent behaviour Razvan Java 19 10-11-2004 04:36 PM



Advertisments