-3

Context: the quiet NaN is not always quiet and may lead to raising of floating-point exceptions.

Code sample & invocations: see QNAN passed into C standard library functions (ex. llrintf): not clear whether FP exceptions are raised or not.

Details: the quiet NaN is quiet only in some cases:

  • arithmetic operations (C11, 5.2.4.2.2, p3)
  • unordered-quiet predicates in Table 5.3 (IEEE 754, 5.11, p4)
  • etc. (you may precise in comments)

Question: Why the creators of C standard have made quiet NaN not always quiet?

pmor
  • 5,392
  • 4
  • 17
  • 36
  • 1
    This looks like an exam question. Do you have some code you can post? Can you identify a real-world problem you're trying to solve? – Robert Harvey Mar 30 '21 at 16:37
  • 1
    "Why the creators of C standard have made quiet NaN not always quiet?" --> To allow for implementations that support quiet and non-quiet (signaling) NAN. – chux - Reinstate Monica Mar 30 '21 at 16:44
  • @RobertHarvey _identify a real-world problem you're trying to solve_: to reach a clear understanding of C and IEEE 754 standards in order to develop (fix existing) C conformant / compliant compiler / standard library. However, [here](https://stackoverflow.com/q/66644353/1778275) user Nate Eldredge asks: _What examples do you know of a combined compiler/library implementation that explicitly claims full ISO C11 conformance? I don't think I know of any_. – pmor Mar 31 '21 at 18:24
  • @chux-ReinstateMonica According to IEEE 754, Table 5.3 `NAN == NAN` shall _not_ lead to raising of FP exceptions. (Note that per C11 macro `NAN` is quiet NaN). However, according to C11, F.4 Floating to integer conversion `lrintf(NAN)` shall lead to _raising of ‘‘invalid’’ floating-point exception_. Hence, I'm trying to understand: why the behavior of FP operations of different type (arithmetic operations, comparisons, conversions, etc.) is not consistent w.r.t. raising of FP exceptions? – pmor Mar 31 '21 at 18:39
  • @pmor Compliant C need not adhere to IEEE 754 nor appendix F. That is optional. "Implementations that do not define __STDC_IEC_559__ are not required to conform to these specifications" – chux - Reinstate Monica Mar 31 '21 at 19:09

1 Answers1

2

Why the creators of C standard have made quiet NaN not always quiet?

As far as I can determine, the C standard does not anywhere specify, directly or indirectly, that there is a circumstance where usage of a quiet NaN must cause a FP exception to be raised. Thus, the standard committee has not made quiet NaN fail to always be quiet.

The committee also has not required that usage of quiet NaNs must never cause a FP exception to be raised, of course, and that allows for (but does not require) cases wherein quiet NaNs do cause FP exceptions. But that does not contradict the previous paragraph.

The standard is designed to support implementation on a wide variety of hardware, and to that end, many details of FP behavior are left unspecified. This allows C to be implemented naturally, in terms of the native FP behavior of the host machine (where that exists). Among other things, C does not specify FP representation, so what the standard means when it talks about NaNs, quiet or otherwise, is more general than what IEEE 754 means by the same terms.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • _a quiet NaN must cause a FP exception to be raised_: `C11, F.4 Floating to integer conversion`: _Otherwise, if the floating value is infinite or NaN or if the integral part of the floating value exceeds the range of the integer type, then the ‘‘invalid’’ floating-point exception is raised and the resulting value is unspecified_. Because it is not specified, which NaN, quiet or signaling, it can be concluded that _any NaN_. Is this conclusion correct? – pmor Mar 31 '21 at 18:11
  • @pmor, *nothing* can be concluded from Annex F for implementations that choose not to define the macro `__STDC_IEC_559__` (see F.1 and and footnote 356). At least some that generally provide IEC 60559 behavior in fact do not define that macro exactly because they do not fully conform to the specifications in that annex, or at least are not prepared to guarantee that they do so. Such implementations do not for that reason fail to conform to the standard. – John Bollinger Mar 31 '21 at 21:10