Yichao Yu <yyc1...@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. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
