On 11/25/20 2:58 AM, Joseph Myers wrote:
glibc effectively treats them as unspecified behavior - we don't expect them to produce any particular meaningful function return value (this includes the possibility that such an invalid encoding might be returned by a function given such an encoding as input), but if they result in buffer overflows, infinite loops or similar, that's fixed as a bug.
Knowing what to call these numbers would be the first step towards knowing what to do with them, which is why I considered classification the first thing to tackle.
Note that there are lots of libm function implementations, not just isnanl, which work by looking at the encoding without considering the possibility it might be one of the kinds of encodings (other than sNaN) that cannot result from floating-point arithmetic. This includes both ldbl-96 implementations in C and implementations in assembly for i386 and x86_64, and probably implementations for m68k and ia64 as well. iscanonical is the only operation in glibc that deliberately tries to detect and produce defined results for these encodings.
Once we have consensus on what unnormals are, it will be much easier for me to work through the toolchain and ensure that we consistently treat them as NaNs.
Would you agree to treating unnormals as NaNs and consequently have glibc provide that guarantee in the library instead of either declaring it undefined or maintaining the status quo, i.e. keeping it unspecified?
Siddhesh
