Re: Bugs in java.lang.Float.FloatTest & java.lang.Double.DoubleTest

[John Leuner <jewel at pixie dot co dot za>]

And what do the Sun jdks do?

John Leuner


On Wed, 2002-09-25 at 15:45, Andrew Haley wrote:
> Stephen Crawley writes:
>  > 
>  > 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.
> 
> I agree with you.  The mandated behaviour is somewhat odd, but that's
> what JLS says.
> 
> Andrew.

Attachment: signature.asc
Description: This is a digitally signed message part