bug#12381: Assume C89 or later for math functions.

[Paul Eggert]

On 09/08/2012 12:07 AM, Eli Zaretskii wrote:

>    Maybe I don't understand what exactly is
>    meant by "floating-point exceptions".

Long ago, before IEEE floating point took over, it was common for
floating point arithmetic to trap when there was an overflow,
causing a C signal, on the theory that this made debugging easier,
or software more reliable, or both.

The IEEE model is different.  It provides exceptional values for
overflow and the like, instead of traps or signals.  This is true even
for floating point exceptions in library functions.  There is a
run-time option that causes exceptions to trap instead, but that
option is off by default, and it's not always supported, and almost
nobody uses it even when it is supported because it's a pain to use
and it's rarely exercised and it tends to be buggy.

So, on current hardware, which is invariably IEEE these days (even on
IBM mainframes!), this issue has not been a problem for many years.
David Golderg's classic paper on the topic
<http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html>
already presented the issue as settled back in 1991, and the
fundamentals haven't changed since then.

>  . Are we sure all supported systems implement the math functions as
>    assumed by this patch?

Yes.  I've already checked that, by looking at the gnulib
documentation for the two functions now assumed (fmod, frexp).  All
the platforms you mention (plus a lot of older and more-obscure
platforms) have them.

>  . Do we really want to remove a possibility of signaling an error on
>    EDOM and ERANGE?

Yes we do.  Nobody configures Emacs that way (it's not documented
anywhere), and there's a good reason: it hasn't been needed for
decades.

>    is it TRT for Emacs to silently continue with HUGE_VAL etc.,
>    disregarding errors in math functions?

Yes, it's clearly the right thing.  It's how Emacs behaves for "+" and
"*", and how Emacs has behave for math functions on GNU platforms, for
many years.  It's the standard behavior, and it's what users expect.

>  . The pieces related to 'matherr' might still be needed on platforms
>    which provide that function....  AFAIR the default version of that
>    function may print an error message, which I think we need to prevent.

matherr was a problem back in the 1980s, but it's been obsolete for
decades.  Platforms that still provide it have it as an SVID option
that is disabled by default, because it was clearly a mistake.  SVID
itself is long dead -- the last SVID spec was published in 1995, and
it's possible that matherr was even gone from SVID by then (the spec
is so old that I can't view it on my Ubuntu machine).

SVID has been supplanted by POSIX, which does not allow the matherr
behavior.  Emacs does not enable the obsolete SVID option on any
platform, so it's fine.

>  . Last, but not least: what exactly does the patch assume about the
>    math library functions?

I think you've pretty much covered the issues.

>    AFAIK you _can_ build a C89 program that will generate SIGFPE
>    in library functions.

That's not a problem in practice, because Emacs does not enable the
optional flags that cause these traps on current porting targets.