Thread: Bit shifting and Endianness

If one writes in C or C++

Code:

int x = 1 << 2;

Is it guaranteed regardless of platform that x is now 4? I was thinking it would have to be, but a friend was claiming that on some platforms the value may be different.

The answer lies in the C standard:

Originally Posted by C99 6.5.7

4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with
zeros. If E1 has an unsigned type, the value of the result is E1 × 2^E2, reduced modulo
one more than the maximum value representable in the result type. If E1 has a signed
type and nonnegative value, and E1 × 2^E2 is representable in the result type, then that is
the resulting value; otherwise, the behavior is undefined.
5 The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type
or if E1 has a signed type and a nonnegative value, the value of the result is the integral
part of the quotient of E1 / 2^E2. If E1 has a signed type and a negative value, the
resulting value is implementation-defined.

Basically, in that case, it will always be 4, regardless of platform, since E1 (1 in your expression) is positive, and E1 * 2^E2 fits in an integer. If you used -2 instead of 2, or E1 was really large (like 2,147,483,647), behavior would be undefined, i.e. you can't trust it on any platform. It's the right-shift operator that is has implementation-defined behavior and may vary from platform to platform.

Originally Posted by Aisthesis

If one writes in C or C++

Code:

int x = 1 << 2;

Is it guaranteed regardless of platform that x is now 4? I was thinking it would have to be, but a friend was claiming that on some platforms the value may be different.

Endianness is relevant only when data is moved from a big endian to a little endian system or vice versa, otherwise the result of computations or comparisons aren't altered.

Originally Posted by iMalc

No, it's also relevant when you have code that treats data as types of different sizes.

Hmm! so what's your point, because that'd be every piece of high level language code

Originally Posted by iMalc

I.e. treating the memory where ints are stored as memory where just chars are stored.

Not sure what you are trying to get at here? How is that going to upset calculations or computations that will be performed? Unless you provide more details I'm unable to see the light of your argument.

Originally Posted by iMalc

Reading it again I still think it's perfectly clear. Perhaps you understand code better:

Code:

int x = 0x12345678;
char *y = (char*)&x;
printf("%c", y[1]);

Nitpick: on systems where sizeof(int) == 1, y[1] is undefined. Something like y[sizeof(int)-1] should work on all systems, though.

Now back to the real world where sizeof(int) >= 2 on most systems anyway....

Originally Posted by iMalc

Reading it again I still think it's perfectly clear. Perhaps you understand code better:

Code:

int x = 0x12345678;
char *y = (char*)&x;
printf("%c", y[1]);

If you could point out the spot where the data was moved between systems with different endianness in the above code, I'd be happy to take my comment back.

In that case you missed the point I was making in my post i.e. endianness doesn't affect computations or comparisons done on disparate systems.

Code:

int i, j, k;
k = i * j;

Will give the same output irrespective of endianness, otherwise what's the point.

Originally Posted by iMalc

If on the other hand you can see now how the above code will simply give different results for the different systems it may be run on then perhaps you understand my comment now.

I was referring to the OP's concern on bit shifting an int quantity, whose output doesn't depend on endianness. Of course walking along an int or float with a char* would print the bytes from the left on big endian and from the right on little endian but that is not a computation or a comparison but merely a way of showing how data is stored in memory on systems with different endianness.

Hope that makes it clear