Of course with well defined overflow you can still end up with a nonsense result that just happens to be in your valid range of values. If you don't plan to harden your code against integer overflow manually you need a language that actively checks it for you or uses a variable sized integer to be safe.

I've spent a fair bit of time running a fuzzer on Rust code that parses untrustworthy data. And the thing that saved my code time and time again was that Rust has runtime bounds checks. Even if I messed up index calculations, I'd get a controlled panic, not a vulnerability.

Ending up with a nonsense result ain't great, but it's still a step up from losing all guarantees about the behaviour of your program.

By the way, throwing an error on overflow is also a perfectly valid way to get defined behaviour and not end up with a nonsense value.

He did harden the code by having an explicit range check.

He is checking if the output is in a sane range. Not if the input values where. This may be correct for a trivial toy example but bite you in actual production code. Fun things like malloc(ab) vs calloc(a,b) where ab overflows in a well defined way and gives you valid pointer to an unexpectedly tiny buffer.

Only correct answer in this thread.

Ah someone else spotted it. The author's code is wrong whether signed overflow is well defined or not.