Re: libgcj/4583: problems BigDecimal(double) ctor.

Re: libgcj/4583: problems BigDecimal(double) ctor.

[tromey]

Synopsis: problems BigDecimal(double) ctor.

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Sun Nov 25 11:32:56 2001
Responsible-Changed-Why:
    I'm handling it.
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Sun Nov 25 11:32:56 2001
State-Changed-Why:
    I checked in a patch on the trunk.
    I also wrote a Mauve test, which we can extend if required.
    If you still have problems please reopen the PR.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4583&database=gcc

Re: libgcj/4583: problems BigDecimal(double) ctor.

[tromey]

The following reply was made to PR libgcj/4583; it has been noted by GNATS.

From: tromey@gcc.gnu.org
To: apbianco@redhat.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  gcc-prs@gcc.gnu.org, java-prs@gcc.gnu.org, nobody@gcc.gnu.org,
  tromey@gcc.gnu.org
Cc:  
Subject: Re: libgcj/4583: problems BigDecimal(double) ctor.
Date: 25 Nov 2001 19:32:56 -0000

 Synopsis: problems BigDecimal(double) ctor.
 
 Responsible-Changed-From-To: unassigned->tromey
 Responsible-Changed-By: tromey
 Responsible-Changed-When: Sun Nov 25 11:32:56 2001
 Responsible-Changed-Why:
     I'm handling it.
 State-Changed-From-To: open->closed
 State-Changed-By: tromey
 State-Changed-When: Sun Nov 25 11:32:56 2001
 State-Changed-Why:
     I checked in a patch on the trunk.
     I also wrote a Mauve test, which we can extend if required.
     If you still have problems please reopen the PR.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4583&database=gcc

libgcj/4583: problems BigDecimal(double) ctor.

[apbianco]

>Number:         4583
>Category:       libgcj
>Synopsis:       problems BigDecimal(double) ctor.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 16 13:26:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Alex Petit-Bianco
>Release:        unknown-1.0
>Organization:
>Environment:
linux/x86, current trunk.
>Description:
I'm running into the following situation with BigDecimal. Consider
this code:

  private static final BigDecimal minDouble =
    new java.math.BigDecimal(Double.MIN_VALUE);

It ends up throwing a java.lang.NumberFormatException.

It seems to be that Long.parseLong doesn't handle what it is given as
an argument (`50E-324', and `scale' in BigDecimal would be modified
accordingly) as Long.parseLong won't handle anything but digits, and
the exception is thrown from there:

  private static long parseLong(String str, int index, int len, boolean isNeg,
                                int radix) throws NumberFormatException
  {
    ...
        if ((digval = Character.digit(str.charAt(index), radix)) < 0)
          throw new NumberFormatException();

Long.parseLong() complies with the spec, but BigDecimal uses
Double.toString to convert the input number. If the input can't be
represented in a string without using the scientific notation,
Long.parseLong() won't receive something it can deal with. 4.0e-4
instead of Double.MIN_VALUE will trigger the same error; but 4.0e-3
won't.

The attached test case can be use and could be added to our testsuite.
>How-To-Repeat:
Build BIG.java.
>Fix:
Not yet. One can work around the problem by hand crafting
a string representation of Double.MIN_VALUE or Double.MAX_VALUE that doesn't use a scientific notation.

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-java; name="BIG.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="BIG.java"

aW1wb3J0IGphdmEubWF0aC5CaWdEZWNpbWFsOwppbXBvcnQgamF2YS5tYXRoLkJpZ0ludGVnZXI7
CgpjbGFzcyBCSUcgewogIHByaXZhdGUgc3RhdGljIGZpbmFsIEJpZ0ludGVnZXIgbWluRG91Ymxl
ID0KICAgIG5ldyBqYXZhLm1hdGguQmlnRGVjaW1hbChEb3VibGUuTUlOX1ZBTFVFKS50b0JpZ0lu
dGVnZXIoKTsKICBwcml2YXRlIHN0YXRpYyBmaW5hbCBCaWdJbnRlZ2VyIG1heERvdWJsZSA9CiAg
ICBuZXcgamF2YS5tYXRoLkJpZ0RlY2ltYWwoRG91YmxlLk1BWF9WQUxVRSkudG9CaWdJbnRlZ2Vy
KCk7CiAgcHVibGljIHN0YXRpYyB2b2lkIG1haW4gKFN0cmluZ1tdIGFyZykKICB7CiAgfQp9Cg==