This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
Bugs in java.lang.Float.FloatTest & java.lang.Double.DoubleTest
- From: Stephen Crawley <crawley at dstc dot edu dot au>
- To: mauve-discuss at sources dot redhat dot com
- Date: Thu, 26 Sep 2002 00:28:30 +1000
- Subject: Bugs in java.lang.Float.FloatTest & java.lang.Double.DoubleTest
Folks,
I think I've found a common bug in the tests for Float.byteValue() and
Double.byteValue(), and I'd like someone to confirm my reasoning before
I fix it.
In gnu.tesrlet.java.lang.float.FloatTest.java we find the following
code fragments:
public void test_shortbyteValue()
{
...
Float d2 = new Float( 400.35 );
...
// 400 doesn't fit in a byte value, so it is
// truncated.
harness.check(!( d2.byteValue() != (byte)127 ),
"Error: test_shortbyteValue failed - 5" );
...
}
Subtest 5 fails on Kissme with the Classpath implementation of
java.lang.Float. The d2.byteValue() call actually returns -112, not
127 as the subtest expects. However, I think that it is the testcase
that is wrong, not Classpath / Kissme.
1) The JDK 1.4 javadoc for Float.byteValue() states that it should
convert the Float's wrapped value to a byte using a type cast.
[This is what the Classpath code does.]
2) The JLS says that a float is narrowed to a byte in two steps.
First, the float is narrowed to an int, then the int is narrowed
to a byte.
a) Narrowing 400.35 to an int gives 400.
b) Narrowing 400 to a byte gives -112.
DoubleTest has an analogous bug.
If someone can confirm my reading of the specs, I'll fix the testcases.
-- Steve