Consider the following snip of java code
byte b=(byte) 0xf1;
byte c=(byte)(b>>4);
byte d=(byte) (b>>>4);
output:
c=0xff
d=0xff
expected output:
c=0x0f
how?
as b in binary 1111 0001
after unsigned right shift 0000 1111
hence 0x0f
but why is it 0xff
how?
The problem is that all arguments are first promoted to
int
before the shift operation takes place:b
is signed, so its value is -15.b
is first sign-extended to the integer-15 = 0xfffffff1
, then shifted right to0xffffffff
and truncated to0xff
by the cast tobyte
.b
is first sign-extended to the integer-15 = 0xfffffff1
, then shifted right to0x0fffffff
and truncated to0xff
by the cast tobyte
.You can do
(b & 0xff) >>> 4
to get the desired effect.According to Bitwise and Bit Shift Operators:
So with
b >> 4
you transform1111 0001
to1111 1111
(b is negative, so it appends1
) which is0xff
.I'd guess that
b
is sign extended toint
before shifting.So this might work as expected:
Java tries to skimp on having explicit support for unsigned basic types by defining the two different shift operators instead.
The question talks about unsigned right shift, but the examples does both (signed and unsigned), and shows the value of the signed shift (>>).
Your calculations would be right for unsigned shift (>>>).