Rust enables overflow checking in debug mode, you can (and I do) enable it in release mode as well.
replyRust's default integer overflow in release mode is defined as well, it'll just wrap around. This makes it less likely to result in a vulnerability (unless you start writing unsafe Rust).
Additionally, integer overflow is less immediately dangerous in Rust, because buffer access is bounds-checked after the arithmetic. You can still get some logic bugs that eventually lead to vulnerabilities, but it's not an arbitrary memory write gadget.
replyWhat convinced me that this is wishful thinking was CVE-2023-53156. Yes, it used "unsafe" but the wraparound in release defeated the manual check, and when you aim for performance comparable to C, Rust tends to be full of unsafe blocks.
replyIMHO better C tooling would be a far better investment than rewriting in Rust.
... do `unsafe {}` blocks not have the same semantics? I thought that was only about memory safety. Or are you thinking of cases where a wrapped-around integer gets interpreted as a pointer or something?
replyunsafe never changes the semantics of anything. Unsafe gives you access to additional features, never changes the meaning of a feature.
replyZig raises overflow. There are +|= and +%= operators for clamped and wrapping addition.
replyRust doesn't raise overflow by default. But you can just 123.checked_add(321). Now your code is unreadable, but it's overflow safe.
Honestly, based on the way I write code I'd rather something like an end of line comment. Like:
var x = y + z; # wrapped
Nobody is going to write "checked_add" because that's too long and people are too lazy. The checked addition should be "+" operator.
replyAgreed, the option that sacrifices security in search of performance should be the more verbose one. There's a reason Rust doesn't have `safe {}` blocks and there's a reason it chose immutable-by-default semantics.
reply