Re: new module 'isfinite'

[Eric Blake]

-----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             address@hidden
-----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-----