Long type, left shift and right shift operations.

Question

Hi

Continuing my previous question http://stackoverflow.com/questions/1782927/why-i-cannot-derive-from-long

I found an interesting problem.

Step one:

4294967296 & 0xFFFFFFFF00000000

Result: 4294967296.

Step two.

4294967296 & 0x00000000FFFFFFFF

Result: 0

Aha, So here I assume that 4294967296 == 0xFFFFFFFF

Let's check

(long)0x00000000FFFFFFFF

Result: 4294967295. Fail.

Let's double check

4294967296 >> 32

Result: 1. Fail.

The only explanation is that because i am using long where some bit is reserved for sign. In C I would use unsigned long. What do you think guys?

Answer 1

4294967296 & 0xFFFFFFFF00000000 = 4294967296

This indicates that the value 4294967296 has no bits set in the lower 32-bits. In fact, 4294967296 is 0x100000000, so this is true.

4294967296 >> 32 = 1

Again, consistent.

In other words, your conclusion that 4294967296 is 0xFFFFFFFF is wrong so the remaining checks will not support this.

Answer 2

I think you are failing to understand the bitwise and operation. The bitwise and will return the bits that are set in both. If the two were the same then

(4294967296 & 0xFFFFFFFF00000000) == 4294967296

and

(4294967296 & 0xFFFFFFFF00000000) == 0xFFFFFFFF00000000

would both hold, but they obviously don't.

Answer 3

Um... I'm not sure why you came to the conclusions you did but 4294967296 is 0x100000000. To write out the bitwise AND's in easily readable hex...

0x0000000100000000 &
0x00000000FFFFFFFF =
0x0000000000000000

0x0000000100000000 &
0xFFFFFFFF00000000 =
0x0000000100000000

Both of those make perfect sense. Perhaps you're misunderstanding a bitwise AND... it maps the bits that are the same in both. Your comments seem more appropriate to a bitwise XOR than a bitwise AND (Which is not the operation you're using)...