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 unsigned right shift operator ( >>> ) (zero-fill right shift) evaluates the left-hand operand as an unsigned number, and shifts the binary representation of that number by the number of bits, modulo 32, specified by the right-hand operand.
That's all about difference between right shift and unsigned right shift operators in Java. Right shift ">>" keeps the sign extension while shifting bit patterns, but right shift without sign doesn't keep the original sign bit intact, it fills with zero.
The right shift operator ( >> ) returns the signed number represented by the result of performing a sign-extending shift of the binary representation of the first operand (evaluated as a two's complement bit string) to the right by the number of bits, modulo 32, specified in the second operand.
Bitwise Zero Fill Right Shift Operator (>>>) Bitwise Zero Fill Right Shift Operator shifts the bits of the number towards the right a specified n number of positions. The sign bit filled with 0's. The symbol >>> represents the Bitwise Zero Fill Right Shift Operator.
The problem is that all arguments are first promoted to int
before the shift operation takes place:
byte b = (byte) 0xf1;
b
is signed, so its value is -15.
byte c = (byte) (b >> 4);
b
is first sign-extended to the integer -15 = 0xfffffff1
, then shifted right to 0xffffffff
and truncated to 0xff
by the cast to byte
.
byte d = (byte) (b >>> 4);
b
is first sign-extended to the integer -15 = 0xfffffff1
, then shifted right to 0x0fffffff
and truncated to 0xff
by the cast to byte
.
You can do (b & 0xff) >>> 4
to get the desired effect.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With