Sven de Marothy wrote:
Actually.. That's where the bug was! :-)
strtod (by ANSI C99) should handle Infinity and NaN.
The problem is the #ifdef on lines 268-273:
#ifdef KISSME_LINUX_USER
val = strtod (p, &endptr);
#else
val = _strtod_r (&reent, p, &endptr);
#endif
The former calls the standard library strtod function, the latter
calls the included fdlibm function.
This appears to be an redundant construct.
I don't quite see the reason here for using the fdlibm strtod.
So the fix for this would be to just replace this with:
val = strtod (p, &endptr);
This works. Of course, this might not work on every C compiler.
But it does work with gcc.
The general reason for the _r forms of various functions is that
the non-_r forms aren't reentrant - i.e. threadsafe. I don'tknow
why/if that is an issue for strtod.
That other issue is that system strtod may not be accurate.
Note that parseDouble is required to return the *closest*
double. This is a difficult requirement to meet, and cannot be done
by simple (i.e. traditional) implementations.
If the strtod in glibc is threadsafe *and* accurate, then we should
probably use it, at least as a default.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath