shifting bits, shift 32 bits on 32 bit int

G

GGG

Noticed something odd in the way bit shifting was working today.

As far as I have ever heard, shifting will shift in zeros(signed ints
aside)

However I foudn something odd when I am shifting exactly the number of
bits in a value... i.e.


uint32_t x = 5;
uint32_t y = x << 32;
uint32_t z = x << 32;

In the above example y and z are both still 5. Why is this?

Now I understand doing a shift like this seems silly, but in this code
sometimes the resulting shift validly turns out to be exactly the
number of bits in that data type, and expects the result to be 0.

I can change the code to handle this special case... I was just
wondering why this was happening..
 
V

Victor Bazarov

GGG said:
Noticed something odd in the way bit shifting was working today.

As far as I have ever heard, shifting will shift in zeros(signed ints
aside)

However I foudn something odd when I am shifting exactly the number of
bits in a value... i.e.


uint32_t x = 5;
uint32_t y = x << 32;
uint32_t z = x << 32;

In the above example y and z are both still 5. Why is this?

Now I understand doing a shift like this seems silly, but in this code
sometimes the resulting shift validly turns out to be exactly the
number of bits in that data type, and expects the result to be 0.

I can change the code to handle this special case... I was just
wondering why this was happening..

It shifts the number of bits determined from the right operand by
taking the remainder from dividing by the number of total bits in
the left operand. Take 32, divide by 32, take the remainder, you
get 0. That's the number of bits shifted to the left. IOW, none.

If you do

uint32_t x = 5;
uint32_t y = x << 33;

you will have y == (uint32_t)10 (most likely, given common meaning
of 'uint32_t').

V
 
W

Walter Tross

Victor Bazarov 2004-05-26 :
It shifts the number of bits determined from the right operand by
taking the remainder from dividing by the number of total bits in
the left operand. Take 32, divide by 32, take the remainder, you
get 0. That's the number of bits shifted to the left. IOW, none.

If you do

uint32_t x = 5;
uint32_t y = x << 33;

you will have y == (uint32_t)10 (most likely, given common meaning
of 'uint32_t').

Exactly, and the reason is simple: most hardware simply takes as many bits
from the shift value as needed, ignoring the higher valued bits.
In the case of uint32_t, 5 bits. In other words,
uint32_t(x) << y == uint32_t(x) << (y & 31)

Walter Tross
 
H

Heinz Ozwirk

uint32_t x = 5;
uint32_t y = x << 32;
uint32_t z = x << 32;

In the above example y and z are both still 5. Why is this?

Now I understand doing a shift like this seems silly, but in this code
sometimes the resulting shift validly turns out to be exactly the
number of bits in that data type, and expects the result to be 0.

It doesn't matter what you are expecting. The behaviour of shifts defined only if the value of the right operand is less than the number of bits in the left operand. So shifting a 32-bit value by 32 or more is undefined or at least not specified in the standard and each compiler may do whatever it thinks to be best.

Heinz
 
G

GGG

Ah... I figured out what was really going on here.

I originally got no compiler warnings from my real program, as the
value I was shifting by was a variable.

I should have payed better attention to my little test program.

uint32_t x = 1 << 32;
//here, x is still 1. Shift any 32 bit int by 32 bits and it stays the
exact same number

That gives a compiler warning because I am shifting by the size of the
data type. The problem here is that it is really just multiplying by
2^32. So... it stays that same. So in reality, shifting doesn't really
"shift in zeros", it does multipication, making it look like it shifts
in zeros. This only becomes apparent when I am shifting by the actual
data type size.


So simply put, if you shift any integer by the number of bits in its
data type, its going to be the exact same number.

Shifting an 8 bit int by 8 bits is NOT 0, it is the same number.
Shifting an 32 bit int by 32 bits is NOT 0, it is the same number.

Kind of interesting I think...
 
J

Jeff Schwab

GGG said:
Ah... I figured out what was really going on here.

I originally got no compiler warnings from my real program, as the
value I was shifting by was a variable.

I should have payed better attention to my little test program.

uint32_t x = 1 << 32;
//here, x is still 1. Shift any 32 bit int by 32 bits and it stays the
exact same number

That gives a compiler warning because I am shifting by the size of the
data type. The problem here is that it is really just multiplying by
2^32. So... it stays that same. So in reality, shifting doesn't really
"shift in zeros", it does multipication, making it look like it shifts
in zeros. This only becomes apparent when I am shifting by the actual
data type size.


So simply put, if you shift any integer by the number of bits in its
data type, its going to be the exact same number.

Shifting an 8 bit int by 8 bits is NOT 0, it is the same number.
Shifting an 32 bit int by 32 bits is NOT 0, it is the same number.

Kind of interesting I think...

You're wrong. Read Heinz's post.
 
J

Jeff Schwab

Jeff said:
You're wrong. Read Heinz's post.

Better yet, read the first part of section 5.8 of the ISO/IEC 14882:2003
standard:

The behavior is undefined if the right operand is negative,
or greater than or equal to the length in bits of the
promoted left operand.
 
J

Jack Klein

It doesn't matter what you are expecting. The behaviour of shifts defined
only if the value of the right operand is less than the number of bits in
the left operand. So shifting a 32-bit value by 32 or more is undefined or
at least not specified in the standard and each compiler may do whatever
it thinks to be best.

Heinz

First, please find the setting in your news posting software where you
tell it to insert line breaks at some interval in the range of 65 to
89 characters. Thank you.

Next, you are partially correct. The value of the right operand must
not only be less than the width in bits of the (promoted) left
operand, it must also be greater than or equal to 0.

Both a negative right operand, or one as large or larger than the
number of bits in the promoted left operand cause undefined behavior.
 
M

Michiel Salters

Ah... I figured out what was really going on here.

I originally got no compiler warnings from my real program, as the
value I was shifting by was a variable.

I should have payed better attention to my little test program.

uint32_t x = 1 << 32;
//here, x is still 1. Shift any 32 bit int by 32 bits and it stays the
exact same number

That gives a compiler warning because I am shifting by the size of the
data type. The problem here is that it is really just multiplying by
2^32. So... it stays that same.

No, it doesn't. Unsigned arithmetic, including multiplying, works modulo
2^n. Multiplying by 2^32 modulo 2^32 always gives you 0.

What happens has been pointed out before: undefined behavior.

Regards,
Michiel Salters
 
G

GGG

Jack Klein said:
First, please find the setting in your news posting software where you
tell it to insert line breaks at some interval in the range of 65 to
89 characters. Thank you.

Next, you are partially correct. The value of the right operand must
not only be less than the width in bits of the (promoted) left
operand, it must also be greater than or equal to 0.

Both a negative right operand, or one as large or larger than the
number of bits in the promoted left operand cause undefined behavior.


Ah, thanks for all the info. Sorry for the long lines... that always annoyed
me too, I am now just stuck no real newsgroup access anymore and it really
blows. I need to use Google to do it...(not to mentioned the ~8 hour delay
when you post on google... I just have to remeber to add in a CR manually
when I post....

Anyways, thanks for setting me straight, my first clue should have been
the compiler warnings that I wasn't paying attention too. Need to pay
better attention...


-grant
 
Joined
Jul 6, 2006
Messages
1
Reaction score
0
Michiel Salters said:
(e-mail address removed) (GGG) wrote in message news:<[email protected]>...

What happens has been pointed out before: undefined behavior.

Regards,
Michiel Salters


I just stumbled over the same problem, in another language though, and was pointed to this thread. Yes, I am aware, that the thread is a quite old one, but it may help as a future reference for others having the same problem ;)

I looked up the Intel spec [1]. The result is /not/ undefined. The Intel spec reads literally:

"The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used)."

Kind regards
//Herbert Glarner



[1] "IA-32 Intel® Architecture Software Developer's Manual, Volume 2B: Instruction Set Reference, N-Z", page 243
 
Last edited:

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top