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

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

[Stephen Crawley]

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


  

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

[Andrew Haley]

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.

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

[John Leuner]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Tom Tromey]

John> And what do the Sun jdks do?

The IBM 1.3 JDK prints -112.
So does the Sun 1.4 JDK.

Tom