Re: new module 'isfinite'

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> Hi Ben,
>
> Paul Eggert wrote:
>> >         * 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 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.