Comment by mlindner
3 years ago
> I'm expecting this article to make the rust crew go in a crusade again, and I think I might be with them this time.
I think he makes a good point. By having overflow be undefined you leave yourself open to all sorts of issues.
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.
1 reply →
Ah someone else spotted it. The author's code is wrong whether signed overflow is well defined or not.