strtod has an upstream source, which has been updated since the version
included in Classpath. I have not yet had the time to look at updating
this, but it is on my TODO list (although not very high priority).
Having done floating point work on the Jikes compiler, I am aware of
several (minor) bugs in the current Classpath implementation of
string/fp and fp/string conversions. The upstream source does use the
underlying architecture's floating point unit, where possible, in
performing the conversions.
And yes, the Java library must implement string conversions itself, to
be platform independent to the last bit. In particular, not all
platforms are IEEE 754 compliant (let alone compliant to the slight
modifications to IEEE 754 required by Java), and not all operating
systems/C libraries have bit accurate conversions. Even the x86
architecture has problems - by using 80-bit registers for internal
computation instead of 64-bit, there are some off-by-one rounding errors
in extreme corner cases.
Thomas Hergenhahn wrote:
Dear all,
I hope this is the right place to post a patch fo libjava.
I'm using libjava from GCC-3.0.4 on Linux i386.
I tried to convert a string of the form 1.234E+000 to a double using
Double.doubleValue(). The result was allways zero (no NumberFormatException).
IMHO, this is a bug. I traced that down until finding the responsible lines
of code in java/lang/strtod.c. The following patch works for me, but better
take a deeper look on it.
BTW, why must libjava implement all this itself? Is it to achieve platform
independency down to the last bit? Does it take advantage of FPU, if one is
present ?
Yours sincerely
Thomas Hergenhahn
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
