Hello, On Sun, 24 Feb 2019 20:25:11 +0100 Szabolcs Nagy wrote: > * Damian McGuckin [2019-02-25 00:28:20 +1100]: > > What comparison of FP numbers trigger invalid operation exceptions? > > > > Does a comparison like > > > > if (x != x) > > { > > /* get to here if x == NaN * > > } > > > > which tests for a NaN cause an invalid operation if given an sNaN? > > iso c does not say much about sNaN: a conforming implementation > does not have to support sNaN (it is usually treated as qNaN, > with unspecified signaling behaviour and you need special > compiler options to ensure sNaN breaking transformations are > not done if you want to rely on sNaN signals) > > with c99 annex F, c == and != operators are mapped to ieee 754 > compareQuiet{Not}Equal, which is non-signaling with qNaN inputs > but signals invalid with sNaN inputs, so in practice sNaN != sNaN > will signal in c. > > > Even reading the standard numerous times and I am not any wiser. > > i think it's better to look at the ieee 754 spec instead > of the c spec, drafts are at http://754r.ucbtest.org/drafts/ > > annex F.3 describes how c is mapped to ieee 754 (iec 60559 > is supposed to be very close to ieee 754). > > ts 18661-* provides more detailed description of the mapping > to ieee 754-2008 (it will likely be part of c2x and it is a > bit more strict than what iso c currently allows). Yes, we are currently integrating parts 1 and 2 of this TS into the standard. Usually you should be able to see a first version of that in a few weeks in the pre-London mailing. For the moment they are integrated "as such" that is with "WANT" macros that make these "new" interfaces optional. Further in the process I hope that we will be able to do a bit more: - Remove this "optionality" from the numbered clauses and make all interfaces mandatory. - Some naming changes while these are not too fixed in peoples minds. Only very few identifiers in are reserved for future use, so adding new interfaces will necessarily step on someones shoes. - Add some version macros for the different header files, such that applications and implementors have better chances to adapt during the time of transition. Jens -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::