Re: New gnulib wrappers with glibc 2.21.

[Pádraig Brady]

On 11/02/15 19:22, Paul Eggert wrote:
> [Also cc'ing bug-gnulib.]
> On 02/11/2015 08:05 AM, Joseph Myers wrote:
>> These bit-patterns are considered to be trap representations
> 
> Yes, this is not a standards-conformance issue.
> 
>> 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.
> 
> Yes, as I understand it the original motivation for this was glibc bug 
> 4586 <https://sourceware.org/bugzilla/show_bug.cgi?id=4586>.  This bug 
> caused GNU 'od' to crash when printing long double data, so we worked 
> around the problem by using isnanl to determine whther a value was a 
> printable number (as opposed to a trap representation that could cause 
> core dumps).  Which meant that isnanl needed to return nonzero on 
> non-canonical representations.
> 
> My impression is that this old problem is no longer relevant, and that 
> we can remove the Gnulib requirement that isnanl must return nonzero on 
> non-canonical representations.  This would mean Gnulib would no longer 
> report problems with x86-64 glibc isnanl.
> 
> If I'm wrong and the old problem is still relevant, or if there's a need 
> for this sort of check in the future, Gnulib should use the new 
> iscanonical macro instead, as it's the one designed for the purpose that 
> Gnulib was using isnanl for.

Invalid values no longer crash, though they may generate surprising results.
See: also https://sourceware.org/bugzilla/show_bug.cgi?id=17661