Tried with gcj 4/3.4 and own compiler with classpath from CVS: Double.toString() gives wrong answer for some inputs. Example: --------------[input]---------- class hi { static double a = 0.0010; public static void main(String args[]) { System.out.println("hi:" + a); } } -----------[outputs]-------------- veldema@faui21e:~/tests> javac hi.java veldema@faui21e:~/tests> java hi hi:0.0010 veldema@faui21e:~/tests> gcj hi.java --main=hi veldema@faui21e:~/tests> ./a.out hi:0.001 -----------[ problem ]----------------- The problematic code is in _dtoa somewhere. Also, shouldn't the call to _dtoa be: _dtoa (value, 0, (isFloat ? 20 : 1), &decpt, &sign, NULL, buffer, (int) isFloat); ???
This is libgcj issue only. Confirmed.
that looks like a bug in Sun's implementation, as the Double.toString() API specs demand that Double.toString returns only as many digits as necessary to uniquely identify the floating point number. Adding one or more '0' digits does not seem useful, as 0.001 and 0.0010 are mathematically speaking the same number. It would in fact seem to violate the API specifications. cheers, dalibor topic
I agree that this is most likely not a libgcj bug. Ronald, why do you think the _dtoa call ought to be changed?
1) I will file a bug report with SUN and see what they say and report back here 2) I read the comments with _dtoa and for floats the arg is interpretted as single-precision if mode >= 16 (seems for a double you both need to pass the isfloat = false && mode == 20 R.
Confirmed, this is a bug in SUN's JDK since 2001. Perhaps a a bug should be introduced to make libgcj/classpath bug compatible ? if (double_string == "0.00x" && x != '0') return return "0.00x0" should do the trick. Ronald.
It seems to be clearly a bug in how some non-free implementation implements the specifications. Since Sun Microsystems has confirmed the bug in their implementation, and the specification is clear on the matter, I don't think it makes sense to make GNU Classpath less compatible. Unless Sun has decided to ammend the API specification, I think this bug should be closed and marked "invalid". cheers, dalibor topic
I would prefer to leave the PR open to address the _dtoa issue. I've updated the PR synopsis to reflect this. I agree that we should not change our toString output, as ours is correct.
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.