This is the mail archive of the
mailing list for the Mauve project.
Bugs in java.lang.Float.FloatTest & java.lang.Double.DoubleTest
- From: Andrew Haley <aph at redhat dot com>
- To: Stephen Crawley <crawley at dstc dot edu dot au>
- Cc: mauve-discuss at sources dot redhat dot com
- Date: Wed, 25 Sep 2002 15:45:21 +0100 (BST)
- Subject: Bugs in java.lang.Float.FloatTest & java.lang.Double.DoubleTest
- References: <200209251428.g8PESU4s001477@piglet.dstc.edu.au>
Stephen Crawley writes:
> 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.
I agree with you. The mandated behaviour is somewhat odd, but that's
what JLS says.