|
Quick Lists
|
|
Bug ID:
|
4723534
|
|
Votes
|
0
|
|
Synopsis
|
multianewarray throws unexpected NegativeArraySizeException
|
|
Category
|
kvm:vm
|
|
Reported Against
|
1.1b8
|
|
Release Fixed
|
|
|
State
|
11-Closed,
Not a Defect,
bug
|
|
Priority:
|
3-Medium
|
|
Related Bugs
|
4433326
|
|
Submit Date
|
31-JUL-2002
|
|
Description
|
The J2SE Virtual Machine specification 6.4 The Java Virtual Machine
Instruction Set, says about multianewarray instruction :
"
...
If any count value is zero, no subsequent dimensions are allocated.
The components of the array in the first dimension are initialized
to subarrays of the type of the second dimension, and so on...
Runtime Exception
Otherwise, if any of the dimensions values on the operand stack are
less than zero, the multianewarray instruction throws
a NegativeArraySizeException. "
The specification is ambiguous.
kvm always throws NegativeArraySizeException when one of the dimension
is negative even if previous one was zero.
But java1.3 and java1.4 do not throw exception in this case, because
they do not check for a negative dimension if one of the previous dimension
was zero.
According to clarification in the bug 4433326:
"The first array element is zero size therefor we silently discontinue
evaluating next array element size...
If user puts [1][-1] an exception will be thrown as desired and spec'd."
To reproduce this bug run the following test:
----------------------B.java--------------------------
public class B {
public static void main (String argv[]) {
int arr [][];
try {
arr = new int[1][-1];
} catch (Exception e) {
System.out.println("Expected exception: "+e);
}
try {
arr = new int[0][-1];
} catch (Exception e) {
System.out.println("FAILD: Unexpected exception: "+e);
return;
}
System.out.println("Ok");
}
}
----------------------------
%% javac -d tmp B.java
%% preverify -d . -classpath tmp:$KVM_PROMOTED/api/classes B
%% kvm -classpath . B
Expected exception: java.lang.NegativeArraySizeException
FAILD: Unexpected exception: java.lang.NegativeArraySizeException
%% java -classpath . B
Expected exception: java.lang.NegativeArraySizeException
Ok
---------------------------
======================================================================
|
|
Work Around
|
N/A
|
|
Evaluation
|
Evaluation excerpt from mail by Tim Lindholm (see comments for complete mail):
I think the JLS clarifies the intention of the JVMS and breaks the
potential ambiguity. JLS 15.10.1, describing the semantics of array
creation expressions, says:
[...]
First, the dimension expressions are evaluated, left-to-right. If
any of the expression evaluations completes abruptly, the expressions
to the right of it are not evaluated.
Next, the values of the dimension expressions are checked. If the
value of any [dimension expression] is less than zero, then an [sic --
"an" can't be right, can it?!] NegativeArraySize Exception is thrown.
Next, space is allocated for the new array. [...allocation of a multi-
dimensional array is given as equivalent to nested for loops each
allocating one dimension...]
I read that to say that all the dimension expressions are evaluated
first, and the only problems noted at this point are expressions that
cannot be evaluated. I do not think that an expression evaluating to
zero can be considered to have completed abruptly. Then *all* the
evaluated dimension values are checked to be nonnegative, and only
after that is space allocated for the new array. I don't see any way
to argue that encountering a zero dimension should terminate the
checking for nonnegative values. But is the case that, as described,
encountering a zero dimension when allocating terminates allocation of the
subarrays. So I conclude that KVM is right, and the test and HotSpot
are wrong!
Unfortunately, this gets us back to a variant of the philosophical
problem: the JLS appears to conflict with a longstanding behavior.
This might turn into something that Gilad and I have to worry about
resolving somehow, and it's possible that resolution would mean
deciding that the spec is in fact in error. But in the meanwhile I
don't think you have a bug.
-- Tim
=========
Closing bug as 'not a bug' as per above evaluation.
xxxxx@xxxxx 2002-08-22
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |