why is 1>>32 == 1? | 易学教程

问题

I'm wondering if perhaps this is a JVM bug?

java version "1.6.0_0" OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu13) OpenJDK 64-Bit Server VM (build 14.0-b08, mixed mode)

class Tmp {
    public static void main(String[] args) {
        System.out.println("1>>1 = "+(1>>1));
        System.out.println("1>>2 = "+(1>>2));
        System.out.println("1>>31 = "+(1>>31));
        System.out.println("1>>32 = "+(1>>32));
        System.out.println("1>>33 = "+(1>>33));
    }
}

produces this when I run it:

1>>1 = 0
1>>2 = 0
1>>31 = 0
1>>32 = 1 <---------- should be 0 i think
1>>33 = 0

I also get the same results for any multiple of 32.

do I need to write my own right-shift to check for this?

回答1:

http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.22.1

15.19 Shift Operators

If the promoted type of the left-hand operand is int, only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (§15.22.1) with the mask value 0x1f. The shift distance actually used is therefore always in the range 0 to 31, inclusive.

If the promoted type of the left-hand operand is long, then only the six lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (§15.22.1) with the mask value 0x3f. The shift distance actually used is therefore always in the range 0 to 63, inclusive.

(emphasis mine)

回答2:

It's not a bug. In n >> m, it only looks at the last five bits of m - so any number greater than 31 will be reduced to that number mod 32. So, (256 >> 37) == 8 is true.

Edit: This is true if you're working with ints. If it's longs, then it looks at the last six bits of m, or mods by 64.

来源：https://stackoverflow.com/questions/3170412/why-is-132-1

标签

java

bit-manipulation