Archie Cobbs wrote:
Per Bothner wrote:
If the strtod in glibc is threadsafe *and* accurate, then we should
probably use it, at least as a default.
Dalibor Topic said on IRC that it has some problems on Irix. So it might
not be a good idea. So perhaps adding a special case would be best, or
you could solve it upstream by adding support for NaN and infinity to
newlib.
Not everybody uses Linux, so what glibc does is not entirely relevant..
glibc is the *GNU* C library, so it's obviously not Linux-specific.
Classpath is the *GNU* Java library, so it isn't unreasonable to
optimize for the glibc case. If on non-glibc platforms floating-point
conversion isn't quite as exact as the spec requires, fixing that is
not a priority. Of course if somebody wants to work on a more portable
solution, that is great, as lang as it doesn't penalize the glibc case.
Semi-agreed.. I just don't like having dependencies on non-standard
features. E.g., if POSIX specifies that strtod() should handle
"NaN", then that's fine. OTOH, if "NaN" is a glibc-only extension
that Classpath relies on, then that's more problematic; it means
Classpath would be broken on all *BSD operating systems for example.
In case it helps:
http://www.opengroup.org/onlinepubs/009695399/functions/strtod.html
http://stevehollasch.com/cgindex/coding/ieeefloat.html
Chris
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
