misleading error message

[Vincent Lefevre]

On 2024-09-25 06:53:14 +0200, Sergey B Kirpichev wrote:
> On Tue, Sep 24, 2024 at 08:13:12PM +0200, marco.bodrato at tutanota.com wrote:
> > I have no particular opinion about "is it better to print a
> > message and abort() or rising SIGFPE?".
> 
> I doubt error message like "Floating point exception" from system
> helps people to identify concrete problem with GMP.

Software that outputs "Floating point exception" should be fixed.

> Especially, as it happens also in other conditions (e.g. sqrt of
> negative integer).

The native integer operation 1 / 0 also gives SIGFPE on x86.
This is not much different.

> > But I think that it should be better to have a single function (eg. __gmp_exception in errno.c) called by every part of code that have to handle a critical error.
> > That way, those that disagree with the answer to the question above have a single file and a single function to change to adapt the library to their needs.
> 
> Well, in gmpy2 we ended with a signal handler that catch SIGFPE, prints some
> specific error message and calls abort().  Patching system-wide installed
> libraries is not an option sometimes...

That's your problem. Using a signal handler or not should be left to
the end user, not to the system libraries. By default, processes just
terminate on SIGFPE (without an error message). The error messages are
generally output by the parent processes (e.g. interactive shells).
The text may come from either the source of the parent process or the
system (e.g. the C library if psignal or psiginfo is used).

> > Actually, the error you refer to is not "memory-related"; it's an
> > overflow of the mpz_t type.
> 
> Indeed, that's more correct.
> 
> Yet I don't see why there couldn't be a single function to handle
> critical errors, that also prints custom error messages before
> calling abort() or raise(SIGFPE).

In general, error messages are bad in libraries. Errors should
be propagated via the API, and messages should be left to the
application. But the point is that erroneous arithmetic operations
should not be critical errors. Raising a signal may be OK, but
the abort() that follows in __gmp_exception() is not, and the
behavior should be specified in case the code is resumed (e.g. if
the signal is ignored or there is a signal handler that doesn't
terminate the process).

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)