Я задаюсь вопросом, является ли, возможно, это ошибкой JVM?
версия "1.6.0_0" Java Среда выполнения OpenJDK (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu13) OpenJDK 64-разрядный Сервер VM (сборка 14.0-b08, смешанный режим)
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));
}
}
производит это, когда я выполняю его:
1>>1 = 0
1>>2 = 0
1>>31 = 0
1>>32 = 1 <---------- should be 0 i think
1>>33 = 0
Я также получаю те же результаты для любого несколько из 32.
я должен записать свой собственный сдвиг вправо для проверки на это?
http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.22.1
15.19 Операторы сдвига
Если повышенный тип левого операнда - int , , только пять младших битов правого операнда используются в качестве расстояния сдвига. Это как если бы правый операнд был подвергнут поразрядному логическому оператору AND & (§15.22.1) со значением маски 0x1f . Таким образом, фактически используемое расстояние сдвига всегда находится в диапазоне от 0 до 31 включительно.
Если расширенный тип левого операнда имеет длину , то только шесть младших битов правого операнда используются в качестве расстояния сдвига . Это как если бы правый операнд был подвергнут поразрядному логическому оператору AND & (§15.22.1) со значением маски 0x3f . Таким образом, фактически используемое расстояние сдвига всегда находится в диапазоне от 0 до 63 включительно.
(выделено мной)
Это не ошибка. В n >> m
он смотрит только на последние пять битов m, поэтому любое число больше 31 будет уменьшено до этого числа по модулю 32. Итак, (256 >> 37) = = 8
верно.
Изменить: это верно, если вы работаете с целыми числами. Если это longs, то он смотрит на последние шесть бит m или на модификации на 64.