-
Bug
-
Resolution: Fixed
-
P4
-
8, 9
-
b04
-
x86
-
linux
FULL PRODUCT VERSION :
A DESCRIPTION OF THE PROBLEM :
On line 465 of BaseFileManager.java (http://hg.openjdk.java.net/jdk9/dev/langtools/file/2aa0433e0add/src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java#l465) I found the following piece of code:
ByteBuffer.allocate(capacity + capacity>>1)
Whitespace suggests that the new capacity is meant to be parsed as "capacity + (capacity>>1)". In fact, however, ">>" binds less tightly than "+" (cf., e.g., https://docs.oracle.com/javase/tutorial/java/nutsandbolts/operators.html), so this is parsed as "(capacity + capacity) >> 1", meaning that the new capacity is the same as the old capacity (except if there is an overflow), which seems unlikely to be the intended behaviour.
The obvious fix would be to introduce parentheses:
ByteBuffer.allocate(capacity + (capacity>>1))
REPRODUCIBILITY :
This bug can be reproduced always.
A DESCRIPTION OF THE PROBLEM :
On line 465 of BaseFileManager.java (http://hg.openjdk.java.net/jdk9/dev/langtools/file/2aa0433e0add/src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java#l465) I found the following piece of code:
ByteBuffer.allocate(capacity + capacity>>1)
Whitespace suggests that the new capacity is meant to be parsed as "capacity + (capacity>>1)". In fact, however, ">>" binds less tightly than "+" (cf., e.g., https://docs.oracle.com/javase/tutorial/java/nutsandbolts/operators.html), so this is parsed as "(capacity + capacity) >> 1", meaning that the new capacity is the same as the old capacity (except if there is an overflow), which seems unlikely to be the intended behaviour.
The obvious fix would be to introduce parentheses:
ByteBuffer.allocate(capacity + (capacity>>1))
REPRODUCIBILITY :
This bug can be reproduced always.
- duplicates
-
JDK-8292022 Issues caused by Unary Plus Operator + and Shift Operators priority
-
- Closed
-