Re: checking against signed integer overflow

[Jeffrey Walton]

On Sun, Dec 6, 2020 at 11:19 PM Bruno Haible <bruno@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