-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [adding the austin group]
According to Paul Eggert on 10/24/2007 4:16 PM: >>>> * Is it acceptable for isfinite to raise an exception on >>>> a signaling NaN? >>> Yes. >> I disagree. We know what the relevant standards say: [1] >> [1] http://lists.gnu.org/archive/html/bug-gnulib/2007-03/msg00396.html > > Hmm, well, I checked into the standards. The C standard explicitly > says it doesn't define the behavior on signaling NaNs. (May 6, 2005 > committee draft, F.2.1.) > > The latest POSIX draft says this (section 4.20): > > On implementations that support the IEC 60559: 1989 standard > floating point, functions with signaling NaN argument(s) shall be > treated as if the function were called with an argument that is a > required domain error and shall return a quiet NaN result, except > where stated otherwise. > > Note: The function might never see the signaling NaN, since it > might trigger when the arguments are evaluated during the function > call. > > The note suggests that, if sNaN is a signaling NaN, then > isfinite(sNaN) can trap even before isfinite starts executing, and > that the caller can't tell the difference between such a trap and > isfinite trapping. isfinite is a macro and not a function, but surely > the same idea applies to macros as well. On the other hand, isless is definitely required to be a macro, and has explicit text stating "isless( x, y) shall not raise the invalid floating-point exception when x and y are unordered", and an application note stating "This macro is a quiet (non-floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the invalid floating-point exception." Similar text is lacking in the descriptions of fpclassify, isnan, isinf, isnormal, and isfinite. > > On implementations that support the IEC 60559: 1989 standard > floating point, for those functions that do not have a documented > domain error, the following shall apply: > > These functions shall fail if: > > Domain Error Any argument is a signaling NaN. > > Either, the integer expression (math_errhandling & > MATH_ERRNO) is non-zero and errno shall be set to [EDOM], or > the integer expression (math_errhandling & MATH_ERREXCEPT) is > non-zero and the invalid floating-point exception shall be > raised. > > Again, isfinite() is a macro and not a function; but isfinite() does > not have a documented domain error, so this spec suggests that > isfinite(sNaN) should either raise an exception, or should return 0 > and set errno to EDOM. > > Personally I agree with you that it's more convenient when isfinite > does not raise an exception. But the bottom line is that portable > code can't assume that isfinite(sNaN) will return 0 without raising an > exception. > I guess it boils down to a question of whether we need to make the text for all of the real-floating macros in <math.h> stronger in stating that signalling NaNs will not raise any exception when processed by the macros. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHH+tP84KuGfSFAYARAo5qAJ9oPmfYWjb/4RzqsPB6KWExFf7quQCfc2XK Jk1pk0cd1+S/cQ+Y4FztYRE= =y0Mo -----END PGP SIGNATURE-----
