On Sun, Dec 6, 2020 at 1:06 PM Paul Eggert <egg...@cs.ucla.edu> wrote: > ... > > So, '-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error' > > and > > '-ftrapv' both work. The former generates better code, whereas the latter > > has > > less surprising behaviour (an abort() is a better response than an illegal > > instruction, IMO). > > Yes, we've discussed this before. I'd rather not have call 'abort' here, since > arithmetic overflow failures are in the same category as dividing by zero or > (INT_MIN / -1) and 'abort' isn't called there either. Calling 'abort' > slightly > complicates the way I debug, and it's just one more thing that can go wrong at > least in theory (stack space exhaustion, PLT corruption, etc.). Plus it bloats > the code a bit.
+1, never call abort(). A library should not be setting policies for a program. It is up to the developer to determine his/her policy. For me reasons why an abort() is bad, see https://www.cryptopp.com/wiki/Assertions#Library_Position. Jeff