Hello,
when I execute the following line of code...
The result is: 80000000, 1, ffffffff. I understand the first two values, but why doesn't the last value = 1. Specifically, when I execute the following..Code:printf("%x, %x, %x\n", (1 << 31), ((0x80000000) >> 31), ((1 << 31) >> 31));
..why are all the bits positioned to the left of the right-bitshift operation set?Code:((1 << 31) >> 31)
Thanks.
Change the %x format specified to %d. You will probably find that some of the values are negative. Bitwise right shift of a signed integer with a negative value has an implementation defined result, e.g., maybe the bits were right shifted with 1 bits used to fill in the "shifted positions", thereby retaining the sign.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Thanks Laserlight. You're right. When I change the printf to the following...
..it "works". The result is: 80000000, 1, 1.Code:printf("%x, %x, %x\n", (1 << 31), ((0x80000000) >> 31), (((uintptr_t)1 << 31) >> 31));
Cheers
The cast to uintptr_t seems semantically wrong. I would expect: ((1u << 31) >> 31));
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I see, much better.
Thanks again.
I thought this was a defined behavior in C (right shifting of signed negative numbers retains the sign). From VS2005
Bitwise Shift Operators (C)
Well, it is defined, implementation defined:
I have taken the liberty of using ** to denote exponentiation.
Hence that implementation has defined how it would deal with such a case.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Was it ever a defined operation in ANSI C or older versions (C89, C90, K&R C)? I have seen it implemented in this same way in some old 1980's compilers for Motorola 68000, Intel X86 and 1990's compilers for the ARM, from several different vendors for each processor type. Seems unusual that they all decided to implement right shift as an arithmetic shift.
One issue I can see is that a ones complement machine would be different than a two's complement machine, but one's complement machines are rare, and I don't know if C99 specifies how signed numbers are to be implemented.
Thanks for the info. I wasn't aware of this, and the microsoft references don't state which operations are implementation dependent.
Last edited by rcgldr; 05-18-2013 at 03:37 PM.
Are constant values like 0x80000000 always considered to be unsigned (for a 32 bit value)?
The rule is the same for C89/C90. I have no clue for K&R.
As far as I remember, there are three options: sign and magnitude, one's complement, and two's complement.
It depends. Since it is in hexadecimal representation, it could be unsigned if it cannot fit into the range of a corresponding signed integer type.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
In K&R, 2nd edition from 1988, it's implementation-defined. There is an appendix which lists all changes to the first edition and the behaviour of right shifts isn't mentioned.
In a tutorial from 1974, Kernighan mentions machines for both arithmetic and logical shifts.
Hence, I guess it was never defined.
Bye, Andreas
On a side note, the "H6070" mentioned in the tutorial refers to the Honeywell 6070 (which was the GE 655). Wiki article:
GE-600 series - Wikipedia, the free encyclopedia
PDP-11:
PDP-11 - Wikipedia, the free encyclopedia
IBM 360:
IBM System/360 - Wikipedia, the free encyclopedia
That tutorial is the first time I've seen C / C++ right shift optionally defined as a logical shift for signed numbers. In all the other instances I'm aware of a right shift on a signed number is arithmetic and copies the sign, at least on two's complement machines.
