4 ms·
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 har
by josefx 4y ago
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.
- 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.