It’s a register based computer problem, not a C problem.

Not checking for overflow is a developer problem

Do you suggest branching after every operation?

a = b + c

if err { // … }

Please note that you should ensure that overflow doesn't happen, not detect when it happens. Once you let it happen, it's undefined behavior.

But you don't need to check each operation to ensure that none of them overflow. If you know that b and c are supposed to be bounded between -10 and +10, for example, the above line can't overflow. So just check that your supposition holds. In most cases, that boils down to a check on the inputs at the entry of the function.

Yes I mentioned that a few posts above;

> Do you prove that every line of arithmetic in your program will not overflow

My point is the analysis takes time, training, and is easy to regress. In practice programs operate within a reasonable N and if you push the limits they will fail. Or the devs wait for a bug report, and then set a pessimistic limit on user input.

Also undefined != crash. Your compiler has options for what to do when signed overflow is detected.

I don'tknow why we are having this discussion. The question was whether I (but I extrapolate to mean every programmer should) prove that not a single line can overflow, and the answer is yes, usually by proving that some variables are bounded.

Of course we can speculate if there are ways to mitigate the effects of, instead of avoiding, overflows, if they are free or come with performance penalties, and if the final result is a crash, a graceful exit, or a continued run as if nothing happened, and which is worse.

For the record, I think the answers are: there are, they're not free, and the latter is the worst.