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. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
