-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
1.4.2
-
x86
-
linux
Name: rmT116609 Date: 04/22/2004
FULL PRODUCT VERSION :
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux Gentoo 2.6.3-gentoo-r1
EXTRA RELEVANT SYSTEM CONFIGURATION :
Purely a language issue
A DESCRIPTION OF THE PROBLEM :
Since a byte is 8 bits, and the octal literal '\177' produces the value 0x7f (01111111) then it would follow the octal literal '\200' would produce the value 0x80 (10000000) since it also represents no more than 8 bits.
However all possible octal literals of '\200' through '\277' produce a single value, namely 0x3f (00111111) which makes no sense at all.
The same holds true for '\u0080' through '\u00ff'
Apparently there is no way to represent a byte value with this notation in the range 0x80 to 0xff, which actually are legitimate byte values in current practice.
That certainly qualifies as a bug.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run this:
public class ShowBug
{
public static void main(String[] arg) {
String s = "ABC"+ '\177' + '\200' + '\277';
for (int i = 0; i < s.length(); i++) {
System.out.print(s.getBytes()[i] + " ");
}
System.out.println();
}
}
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
One would expect:
65 66 67 127 128 255
or
65 66 67 127 -0 -1
or in hex:
0x41 0x42 0x43 0x7f 0x80 0xff
ACTUAL -
Instead, one gets
65 66 67 127 63 63
or in hex:
0x41 0x42 0x43 0x7f 0x3f 0x3f
ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages in compilation or execution
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class ShowBug
{
public static void main(String[] arg) {
String s = "ABC"+ '\177' + '\200' + '\277';
for (int i = 0; i < s.length(); i++) {
System.out.print("0x" + Integer.toHexString(s.getBytes()[i]) + " ");
}
System.out.println();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There are workarounds, but none provide the clarity of expression as in the example.
Such expressions are much clearer in initializing byte arrays than are long lists of individual calls to methods that locate the next postion of the array to be loaded.
Besides, an octal representation of 8 bits should certainly not be dependent on the value of the number and produce a constant incomprehensible result if out of the permissible range without error.
(Incident Review ID: 246757)
======================================================================
FULL PRODUCT VERSION :
java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux Gentoo 2.6.3-gentoo-r1
EXTRA RELEVANT SYSTEM CONFIGURATION :
Purely a language issue
A DESCRIPTION OF THE PROBLEM :
Since a byte is 8 bits, and the octal literal '\177' produces the value 0x7f (01111111) then it would follow the octal literal '\200' would produce the value 0x80 (10000000) since it also represents no more than 8 bits.
However all possible octal literals of '\200' through '\277' produce a single value, namely 0x3f (00111111) which makes no sense at all.
The same holds true for '\u0080' through '\u00ff'
Apparently there is no way to represent a byte value with this notation in the range 0x80 to 0xff, which actually are legitimate byte values in current practice.
That certainly qualifies as a bug.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run this:
public class ShowBug
{
public static void main(String[] arg) {
String s = "ABC"+ '\177' + '\200' + '\277';
for (int i = 0; i < s.length(); i++) {
System.out.print(s.getBytes()[i] + " ");
}
System.out.println();
}
}
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
One would expect:
65 66 67 127 128 255
or
65 66 67 127 -0 -1
or in hex:
0x41 0x42 0x43 0x7f 0x80 0xff
ACTUAL -
Instead, one gets
65 66 67 127 63 63
or in hex:
0x41 0x42 0x43 0x7f 0x3f 0x3f
ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages in compilation or execution
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class ShowBug
{
public static void main(String[] arg) {
String s = "ABC"+ '\177' + '\200' + '\277';
for (int i = 0; i < s.length(); i++) {
System.out.print("0x" + Integer.toHexString(s.getBytes()[i]) + " ");
}
System.out.println();
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
There are workarounds, but none provide the clarity of expression as in the example.
Such expressions are much clearer in initializing byte arrays than are long lists of individual calls to methods that locate the next postion of the array to be loaded.
Besides, an octal representation of 8 bits should certainly not be dependent on the value of the number and produce a constant incomprehensible result if out of the permissible range without error.
(Incident Review ID: 246757)
======================================================================