This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: V3 PATCH: numeric_limits<> support, fix PR/3865
- From: Roger Sayle <roger at eyesopen dot com>
- To: <gcc-patches at gcc dot gnu dot org>, <libstdc++ at gcc dot gnu dot org>
- Cc: Ulrich Drepper <drepper at redhat dot com>, Richard Henderson <rth at redhat dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Mon, 2 Sep 2002 14:30:12 -0600 (MDT)
- Subject: Re: V3 PATCH: numeric_limits<> support, fix PR/3865
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