This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: New gnulib wrappers with glibc 2.21.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 11 Feb 2015 16:05:36 +0000
- Subject: Re: New gnulib wrappers with glibc 2.21.
- Authentication-results: sourceware.org; auth=none
- References: <54D91281 dot 8080203 at redhat dot com> <54DA9BB3 dot 2050308 at cs dot ucla dot edu>
On Tue, 10 Feb 2015, Paul Eggert wrote:
> The isnan* failures were because glibc isnanl etc. don't consider
> pseudo-denormals to be NaNs; see
> <https://www.gnu.org/software/gnulib/manual/html_node/isnan.html>. I don't see
> a bug report filed for this, perhaps one should be.
(The following concerns x86_64 / x86, without having checked what would be
appropriate for ia64 or m68k.)
These bit-patterns are considered to be trap representations, i.e. not
representations of any valid value and with no expectation that they
behave consistently like any valid value when passed to glibc functions.
Treating pseudo-denormals as NaNs isn't even consistent with how they work
in arithmetic instructions, unlike the other trap representations which
act like signaling NaNs in instructions. So with the gnulib
implementation they are still trap representations (not consistently
behaving like NaNs), you've just made a different choice of how to handle
them.
The most I think would be reasonable for glibc to ensure for these
representations (and similarly for representations of IBM long double that
do not conform to the format and so do not represent any valid value) is:
* Passing such values to glibc functions does not cause a crash, but
returned floating-point values, string representations for functions
converting floating-point to strings, and exceptions raised, are
unspecified.
* The iscanonical macro (TS 18661-1, not currently implemented) identifies
all such representations as non-canonical (although formally it's not
required to, as it's only required to work on valid values, not trap
representations).
* The canonicalizel function (TS 18661-1, not currently implemented)
produces the same results as 1.0 * (VALUE) does (rather than failing,
which would also be OK for a trap representation). For pseudo-denormals
this result would not be a NaN; for the other trap representations it
would be a quiet NaN with "invalid" raised.
--
Joseph S. Myers
joseph@codesourcery.com