The behavior of >> varies from language to language. In C and Java, >> is the arithmetic right shift operator. I believe the previous two posts by jaeusm and Chankama have almost covered how >> is handled.
You both are correct under intuitive circumstances. In A >> B, you were considering A to be an unsigned integer. If we allow A to be signed, we will run into problems. Take the previous example:
0xF = 1111
If 0xF is unsigned:
1111 >> 2 = 0011
or equivalently:
15 >> 2 = 3.
Unfortunately, C and Java handle arithmetic right shift differently. It seems C forces the number being shifted to be unsigned. Java uses the 'correct' definition of arithmetic right shift and propagates the most significant bit in the result (known as sign extension):
1111 >> 2 = 1111
equivalently in decimal:
-1 >> 2 = -1
or using a different example:
1100 >> 1 = 1110
equivalently in decimal:
-4 >> 1 = -2
Verify:
http://en.wikipedia.org/wiki/Bitwise...2B.2C_and_Java
Note I am using 2's complement for the representation of the signed integers.
If you ask me, 0xfaceb00c >> 2 is an idiotic thing for the facebook recruiting team to use as an email address. I know they're trying to be clever, but honestly, I hope the engineers exercise a higher degree of finite precision in their daily work than they do in describing their obscure email addresses.