3 ms·
> 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
by mlindner 4y 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.
- josefx 4y agoOf 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.
- p0nce 4y agoAh someone else spotted it. The author's code is wrong whether signed overflow is well defined or not.
- ekidd 4y agoI'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.
- eru 4y agoEnding 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.
- deleted 4y ago[deleted]
- silon42 4y agoHe did harden the code by having an explicit range check.
- josefx 4y agoHe 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.
- p0nce 4y agoOnly correct answer in this thread.