|
From: | Per Bothner |
Subject: | Re: bug 10491 was Re: More astonishing progress in japi scores |
Date: | Thu, 07 Oct 2004 09:01:05 -0700 |
User-agent: | Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040803 |
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 lattercalls 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/
[Prev in Thread] | Current Thread | [Next in Thread] |