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

Reply via email to