This is the mail archive of the
mailing list for the glibc project.
Re: New gnulib wrappers with glibc 2.21.
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Gnulib bugs <bug-gnulib at gnu dot org>
- Date: Wed, 11 Feb 2015 11:22:07 -0800
- 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> <alpine dot DEB dot 2 dot 10 dot 1502111539380 dot 24912 at digraph dot polyomino dot org dot uk>
[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
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.