Re: bug 10491 was Re: More astonishing progress in japi scores

[Per Bothner]

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
address@hidden   http://per.bothner.com/