[Issue 2388] type of NaN given by real.nan not specified

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Oct 6 04:09:47 PDT 2008


http://d.puremagic.com/issues/show_bug.cgi?id=2388


clugdbug at yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




------- Comment #2 from clugdbug at yahoo.com.au  2008-10-06 06:09 -------
There would, however, be significant value in specifying what the payload of
real.nan (and real.init) is. If it were specified, we could distinguish
uninitialised variables from machine nans.

Eg, on X86, the result of multiplying infinity by zero (or any other prohibited
operation) is 0x1.7FFFFFp+NaN. If real.init was guaranteed to be different to
this, then the I/O functions could display something like "nan(init)" for
uninitalized variables, and "nan(ind)" for prohibited operations giving an
indeterminate result.

Identification of a machine nan is CPU-specific, but is trivial in all cases.

IEEE 754-2008 (finally approved a few weeks ago!) includes the statement:
---
Languages should provide an optional conversion of NaNs in internal format to
external character sequences that appends to the basic NaN character sequences
a suffix that can represent the NaN payload (see 8.2). The form and
interpretation of the payload suffix is language defined. The language should
require that any such optional output sequences be recognized as input in
conversion of external character sequences to internal formats.
---
So the use of NaN payloads is now officially mandated.

Reopening this as an enhancement. I recommend a payload with the MSB set and
all other bits zero.


-- 



More information about the Digitalmars-d-bugs mailing list