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: PÃdraig Brady <P at draigBrady dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, Joseph Myers <joseph at codesourcery dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Gnulib bugs <bug-gnulib at gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 11 Feb 2015 19:38:09 +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> <alpine dot DEB dot 2 dot 10 dot 1502111539380 dot 24912 at digraph dot polyomino dot org dot uk> <54DBABDF dot 6080903 at cs dot ucla dot edu>
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