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
