This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New gnulib wrappers with glibc 2.21.

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
> <>. 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 

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 

* 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 

* 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]