On Sun, Dec 6, 2020 at 11:19 PM Bruno Haible <br...@clisp.org> wrote: > > Paul Eggert wrote: > > At this point it would be better for integer arithmetic overflow to > > generate SIGFPE in some way that a signal handler could tell the > > difference, but > > this is not a hill I'm prepared to die on and if it requires significantly > > more > > runtime library code or extra instructions in the executable I wouldn't > > bother. > > While glibc already documents that SIGFPE could be signalled for integer > overflow, with code FPE_INTOVF_TRAP [1], I don't know how user-space code > could generate such a signal: raise() doesn't take a second argument, > and sigqueue() sets the code to SI_QUEUE, not FPE_INTOVF_TRAP. [2]
Another thing to be careful of is, if there is no signal handler in place (like for SIGTRAP), then what happens after the signal is raised depends on the OS. I believe Linux will allow the program to continue after an uncaught SIGTRAP. Modern OS X will still abort even though that's the exact behavior you are trying to avoid by not using asserts with its SIGABRT. And one more point about asynchronous signals... They disgorge the point of failure from the handler. I think the best strategy is to use an API that returns an immediate result. The program then can handle the failure as it sees fit at the point of failure, and not some callback with restrictions. Jeff
