V3 PATCH: numeric_limits<> support, fix PR/3865
Roger Sayle
roger@eyesopen.com
Mon Sep 2 13:44:00 GMT 2002
Hi Richard,
> I suppose we could define "snan" (case insensitive) to do what we
> want. I'd bet that Uli would be willing to pick this up for glibc's
> strtod implementation. We'd probably be "inconsistent" with other
> libcs, but in an extremely minor way.
I believe a relevant document might be N965 "Optional support for
Signaling NaNs" from WG14.
http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
In this draft, the suggested extension to strtod is to use "NANS"
rather than "snan" (as proposed by RTH). The effect is the same,
but it looks as though the standards commitee has already but some
thought into what the details should look like, and which functions
are affected.
As a first step, the "-fsignaling-nans" option to GCC will define
the __SUPPORT_SNAN__ macro defined in that document.
For my two cents, I support Ulrich that adding __builtin_nan,
__builtin_qnan, __builtin_snan and __builtin_inf to GCC would be
a convenient starting print, upon which glibc and libstdc++ could
portably implement the functionality described in the above draft
standard.
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
More information about the Libstdc++
mailing list