Pull request: Raise SIGFPE instead of abort in __gmp_exception`

[Niels Möller]

Yichao Yu <yyc1992 at gmail.com> writes:

> However, if I understand correctly, this may cause a regression on OSX
> x64 for multi-threaded programs since the signal may be delivered to
> any thread instead of the current thread.

I don't fully understand the consequences, but if raise ever returns for
any reason, __gmp_exception will go on and divide by zero, and if that
doesn't cause program termination, it will next call abort.

Posix seems pretty clear that raise must deliver the signal to the
thread executing raise.
http://pubs.opengroup.org/onlinepubs/009695399/functions/raise.html. And
the C standard says at least that "If a signal handler is called, the
raise function shall not return until after the signal handler does."
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf 

It's possible to add som OSX workaround, say 

  #if defined (SIGFPE) && defined (MAC_SOMETHING)

But I'd prefer to do that only if there's any real problem. After all,
the typical action is that the program is terminated, and if a signal
handler is installed, it typically just adds a friendlier error message
before termination.

> Unconditionally trying the old approach first should solve this issue.

You mean, first try divide by zero, and in case that doesn't crash the
program, raise a signal? If we want the specific signal SIGFPE, then I
think using raise is preferable, because it has a reasonably well
defined meaning in C. While division by zero is undefined behaviour.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.