   bit rotation instead of shift?
  Hi!While I was shifting a 32 bit value (0xFFFFFFFF) to the right by 32 bits, I was expecting a 0 as a result. Instead, the value didn't change. It seems that the compiler interprets it correct and I assume it's the pentium processor, which does it.Has anyone encountered this problem before?I worked around the problem by using 0x7FFFFFFF and shifting it by 31 but I was wondering why it did it.Thanks.   
  The behaviour of right bit shifting changes if the value is signed or unsigned. Right bit shifting a signed value will preserve the sign. In other words, if the value is negative the most significant bit after a right shift will be 1.Right shiting an unsigned value will always make the most significant bit be equal to 0.;  If your number signed?  right shifts on negative unsigned integers are undefined.( often they're done such that the unspecified bits are filled with the MSB, so that negative values stay negative.  If you think of your ">>32" as ">>1" 32 times, then it's understandable )Of course, your compiler might hae just removed it entirely, since the result of a 32-bit shift on a 32-bit number is pretty useless.   ;  I was using an unsigned integer. It was not removed, because it's not always 32 (The disassembly proves me right). But if it's 32 the problem I stated occurs.   ;Quote:Original post by me22If your number signed?  right shifts on negative unsigned integers are undefined.That is incorrect. Right shifting is defined for signed and unsigned integers.;  I'm not sure what the standard says about it but modern x86 processors (386+) have a 'bug' which simply clips the bit count. Some compilers deal with this for constant shift counts but a variable shift by x for a 32-bit integer is equivalent to 'value >> (x & 31)'. There isn't much you can do about this flaw except for dealing with it manually.Quote:Original post by Anonymous PosterQuote:Original post by me22If your number signed?  right shifts on negative unsigned integers are undefined.That is incorrect. Right shifting is defined for signed and unsigned integers.Again, I'm not sure of the exact wording of the standard (as I don't have access to it), but it's often stated that it doesn't require arithmetic right shifts for signed integers.   ;Quote:Original post by Anonymous PosterQuote:Original post by me22If your number signed?  right shifts on negative unsigned integers are undefined.That is incorrect. Right shifting is defined for signed and unsigned integers.In some languages, perhaps.In C++, at least the upper bits are unspecified.   ;  Michael Abrash ran into the same issue some years ago - I guess this is written in his black book. Now, it doesn't make much sense to create a zeroed value using this way: you have to load the register with your 32 bit value, and then shift it. Why don't you just load your register with 0? You compiler is smart enough: since 0 is a special value, it will do its best to create the fastest possible code (maybe he will simply "xor eax, eax", maybe it will load 0 into eax, ...).What was your goal?Regards,   ;  Shifts by numbers that are bigger than the size of the register, or are negative have undefined results by the standard (iirc).VS2005 will in fact give you a warning about constant shift values that are out of range:warning C4293: '>>' : shift count negative or too big, undefined behaviorStill, it does seem like you're going to an awful lot of trouble to simply set a variable to zero, when you can directly do exactly that.   ;  Right shifting a signed integer is implementation defined, according to the C++ standard. Worse still, I've seen GCC and VC do different things even on x86.   