ISO/ IEC JTC1/SC22/WG14 N747

 Document Number: WG14 N747/J11 97-110
 C9X Revision Proposal
 =====================
 Title: IEC 559 Binding: Signaling NaNs
 Author: Fred J. Tydeman
 Author Affiliation: Tydeman Consulting
 Postal Address: 3711 Del Robles Dr., Austin, Texas, USA, 78727
 E-mail Address: tydeman@tybor.com
 Telephone Number: +1 (512) 255-8696
 Fax Number: +1 (512) 255-8696
 Sponsor: WG14
 Date: 1997年09月16日
 Proposal Category:
 __ Editorial change/non-normative contribution
 Y_ Correction
 Y_ New feature
 __ Addition to obsolescent feature list
 __ Addition to Future Directions
 __ Other (please specify) ______________________________
 Area of Standard Affected:
 __ Environment
 __ Language
 __ Preprocessor
 Y_ Library
 Y_ Macro/typedef/tag name
 Y_ Function
 __ Header
 __ Other (please specify) ______________________________
 Prior Art: None known.
 Target Audience: Programmers that need to detect use of
 uninitialized floating-point variables._____________________
 Related Documents (if any): C9X working draft 10; IEC 559
 or IEEE-754; IEEE-854.
 Proposal Attached: _Y Yes __ No, but what's your interest?
 Abstract: IEC 559 (IEEE-754) requires Signaling NaNs.
 Signaling NaNs are missing from the current C9X binding of
 IEC 559. This adds them so that the C binding of IEC 559
 conforms to all the required parts of IEC 559. This also is
 a prerequisite to adding LIA-1 to C9X, but only because it
 is a required feature of IEC 559.
 This is being proposed because it is a 'required' feature,
 not because it is a useful feature.
 [ISSUE: What to do with this?
 1) Add as changes to existing body and annexes. That is how
 this is currently written.
 2) Add as new informative annex. We need to say in C9X that
 signaling NaNs of IEC 559 are not required (that is, have
 C9X overrides IEC 559 (and LIA-1) on this one point).
 3) Drop.]
 Proposal:
 -- Add to subclause 7.7 Mathematics <math.h>:
 The macros
 NANSF
 NANS
 NANSL
 are respectively float, double, and long double versions of
 signaling NaNs. They are defined if and only if the
 implementation supports signaling NaNs for the indicated
 type. They expand to a constant expression, suitable for
 static and aggregate initialization, representing an
 implementation-defined signaling NaN.
 -- Add a new paragraph after the NANS macros and before the
 number classification macros:
 The macros
 COPY_NANSF_SIGNALS
 COPY_NANS_SIGNALS
 COPY_NANSL_SIGNALS
 expand to boolean constants to indicate whether copying,
 such as by assignment, a signaling NaN without a change of
 format signals the invalid operation exception. They are
 defined if and only if the implementation supports signaling
 NaNs for the indicated type.
 [ISSUE: Should these have three values: never(0), always(1),
 and sometimes(-1)? I can see a need for sometimes, as it
 may depend upon code optimization level.]
 [ISSUE: Do we need a macro for each floating format? I
 assume some implementations do assignment as a load/store
 into/from long double registers, so floats and doubles would
 signal, but long doubles would not.]
 [ISSUE: Do we need macros to indicate if passing a signaling
 NaN by value (assigning argument to parameter) in a function
 call signals invalid?]
 [ISSUE: Do we need macros to indicate if returning a
 signaling NaN from a function call signals invalid?]
 -- Add to the list of macros for number classification in
 subsection 7.7 <math.h> after FP_NAN:
 FP_NANS
 -- In fpclassify (subsection 7.7.2.1), change:
 The fpclassify macro classifies its argument value as NaN,
 infinite,
 to:
 The fpclassify macro classifies its argument value as
 signaling NaN, quiet NaN, infinite,
 -- [ISSUE: Do we need a function similar to 7.7.11.2 nan
 function to create signaling NaN? It would return void and
 be passed the address of where to store the NANSF/NANS/NANSL
 as well as the pointer to the n-char-sequence. I believe
 that none of IEC 559, LIA-1, and LIA-2 require such a
 function.]
 -- In F.2 Types, change:
 247. A non-IEC 559 long double type must provide
 infinities and NaNs, as its values must include all
 double values.
 to:
 247. A non-IEC 559 long double type must provide
 signaling NaNs, quiet NaNs, and infinities, as its
 values must include all double values.
 -- In F.2.1 Infinities, signed zeros, and NaNs, change:
 This specification does not define the behavior of
 signaling NaNs.248 It generally uses the term NaN to
 denote quiet NaNs. The NAN and INFINITY macros and the
 nan function in <math.h> provide designations for IEC
 559 NaNs and infinities.
 to:
 This specification does define the behavior of signaling
 NaNs since they are a required feature of IEC 559.248 It
 generally uses the term NaN to denote quiet NaNs. The
 NAN, NANSF, NANS, NANSL and INFINITY macros and the nan
 function in <math.h> provide designations for IEC 559
 NaNs and infinities.
 -- In Subsection F.3, last item, add FP_NANS to the
 list of classification macros. Also, replace: "IEC 559
 (except that fpclassify does not distinguish signaling from
 quiet NaNs)" with "IEC 559. The signbit and fpclassify
 macros do not raise invalid for signaling NaNs." in the same
 paragraph.
 -- In subsection F.3, add: The isnan macro shall (should?)
 not raise invalid for signaling NaNs.
 -- In subsection F.9, change:
 Generally, one-parameter functions of a NaN argument
 return that same NaN and raise no exception.
 to:
 Generally, two-parameter functions with either or both
 arguments being a signaling or quiet NaN return the sum of
 those two arguments. If either argument was a signaling NaN,
 invalid is raised. That way the function acts like a basic
 arithmetic operation for NaN propagation.
 Generally, one-parameter functions of a signaling NaN
 argument return that signaling NaN made quiet and raise
 invalid. None of the standards specify how a signaling
 NaN is replaced by a quiet NaN; just that a quiet NaN
 shall be the result if no trap happens. The function f(x)
 should use x+x as the means to make a signaling NaN quiet,
 so as to act like a basic arithmetic operation for NaN
 propagation. 
 Generally, one-parameter functions of a quiet NaN argument
 return that same quiet NaN and raise no exception.
 --
 In subsection F.8.2 Expression transformations, change:
 256. Strict support for signaling NaNs - not required by
 this specification - would invalidate these and other
 transformations that remove arithmetic operators.
 to:
 256. Strict support for signaling NaNs would invalidate
 these and other transformations that remove arithmetic
 operators.
 -- Add to F.9.1.4 The atan2 function before the item on
 (quiet) NaNs:
 - atan2(y,x) returns y/x and raises invalid if both
 arguments are signaling NaNs.
 - If one argument is a signaling NaN then atan2 returns
 that NaN made quiet and raises invalid.
 -- Add to F.9.4.2 The hypot function before the item on
 (quiet) NaNs:
 - hypot(x,y) returns x+y and raises invalid if both
 arguments are signaling NaNs.
 - If one argument is a signaling NaN then hypot returns
 that NaN made quiet and raises invalid.
 -- Add to F.9.4.3 The pow function before the item on
 (quiet) NaNs:
 - pow(x,y) returns x+y and raises invalid if both
 arguments are signaling NaNs.
 - If one argument is a signaling NaN then pow returns
 that NaN made quiet and raises invalid.
 [ISSUE: is pow(NANS,0.0) invalid or 1.0?]
 -- Add to F.9.7.1 The fmod function before the item on
 (quiet) NaNs:
 - fmod(x,y) returns x/y and raises invalid if both
 arguments are signaling NaNs.
 - If one argument is a signaling NaN then fmod returns
 that NaN made quiet and raises invalid.
 -- Add to F.9.8.3 The nextafter function before the item on
 (quiet) NaNs:
 - nextafter(x,y) returns x+y and raises invalid if both
 arguments are signaling NaNs.
 - If one argument is a signaling NaN then nextafter returns
 that NaN made quiet and raises invalid.
 -- Add to F.9.9.1 The fdim function before the item on
 (quiet) NaNs:
 - fdim(x,y) returns x+y and raises invalid if both
 arguments are signaling NaNs.
 - If one argument is a signaling NaN then fdim returns
 that NaN made quiet and raises invalid.
 -- Add to F.9.9.2 The fmax function before the item on
 (quiet) NaNs:
 - fmax(x,y) returns x+y and raises invalid if both
 arguments are signaling NaNs.
 - If one argument is a signaling NaN then fmax returns
 that NaN made quiet and raises invalid.
 [ISSUE: That last item differs from fmax(1.0,NAN) being
 1.0 instead of NAN.]
 -- I/O
 [ISSUE: Do we need to specify printing Signaling NaNs? I
 believe that there is no assurance that a NANS can be
 passed to printf, therefore, the NANS cannot be detected to
 be printed. We could make it implementation defined.]
 [ISSUE: Do we need to specify inputing Signaling NaNs? I
 believe that there is no assurance that a NANS can be
 returned from strtod. On the other hand, scanf could store
 a NANS via the pointer passed to scanf. We could make
 store via pointer be required and store via return be
 implementation defined.]
 IEEE-854 in section 5.6 Floating-Point <--> Decimal String
 Conversion has:
	 The letters "NaN," case insensitive, optionally
	 preceded by an algebraic sign, should be the first
	 characters of a string representing a NaN.
	 Unless recognized as a quiet NaN on input, an
	 input NaN should become a signaling NaN.
 These are enhancements to IEEE-754 which has "NaNs encoded
 in decimal strings are not specified in this standard."
 -- Complex
 [ISSUE: In G.5.1 Multiplicative operators, is:
 [#4] A complex or imaginary value with at least one
 infinite part is regarded as an infinity (even if its
 other part is a NaN).
 still true if the NaN is a signaling NaN?]
 -- Uninitialized variable usage detection
 For NaNs to be useful as a means to detect the use of a
 floating-point value before it has been assigned a value
 would require a change to the existing C language. Since
 the bit pattern of all ones in a IEEE-754 single and double
 are NaNs (the same is true for most, if not all, double
 extended formats), setting static, automatic, and heap
 floating-point variables to all ones would produce NaNs
 in place of undefined values. Unfortunately, the all ones
 bit pattern is not required to be a signaling NaN, it can be
 a quiet NaN. This idea also goes against the existing C where
 some variables are set to zero at creation. If this were
 supported, it would have to be under a pragma so that the
 user can ask for this all ones as well as the current zeros.