<
https://en.wikipedia.org/wiki/IEEE_754#Formats>: "A NaN may carry a
payload that is intended for diagnostic information indicating the
source of the NaN." A NaN is represented by a biased-exponent field that
is filled with 1 bits, and a non-zero significand. The payload is stored
in the significand.
I'd cite IEEE 754 directly, if I could - but I don't have a copy of it.
I do have a copy of IEEE 854, which is a radix-independent variant of
IEEE 754, but I don't have it with me right now.
C++ does not mandate conformance with IEEE 754, but if
std::numeric_limits<T>::is_iec559 is true, then T conforms to IEC 559
(== ANSI/IEEE 754), and that is is overwhelmingly the most commonly
supported floating point standard. I think that some of the other
floating point standards may have a similar feature.
The specification for the strtod() function is incorporated by reference
from the C standard. Section 7.22.1.3p3 and p4 of the C standard specify
that a string starting with an optional sign followed by NAN will
produce a NAN, and that the "NAN" may optionally followed by sequence of
digits and nondigits - which sequences are allowed and what they mean is
implementation-defined (you might expect that everything is either a
digit or a non-digit, but that's not how those terms are defined. The
character '_', the roman letters 'a' through 'z' and 'A' through 'Z',
and any UCN are guaranteed to qualify as nondigits. Any other characters
that qualify as nondigits are implementation-defined - C standard
6.4.2.1p1).
The description of the iostreams library does not describe the handling
of NANs directly - it describes the relevant functions as equivalent to
calls to members of the printf() family of functions. The definitions of
those functions are incorporated by reference from the C standard.
Section 7.21.6.1p8 of the C standard specifies that if you print a NaN,
the output will start with an optional '-' followed by "nan" (if you use
%f, %e, %g, or %a) or "NAN" (if you use %F, %E, %G, or %A) optionally
followed by an implementation-defined sequence of characters.
Both ends of this process are entirely implementation-defined, which
allows an implementation to make full use of IEEE 754 NaNs with
payloads, or not, at the implementor's discretion. I would expect most
implementations which support NaN payloads to define the character
string produced by printf() of a NaN to match the string passed to
strtod() to create that NaN.
Thus, code which creates a NaN using strtod() can encode a limited
amount of information about the context in which it was created, which
can be decoded by printing the NaN.