Yet another reason not to use Rust.
Conversation
What's your disagreement with Rust's overflow behavior?
1
It gives you the option when that's what you want. Why would you want that to be the default?
1
But that's just rephrasing the question. Why would you define int math that way? Is it due to concern about unexpected traps escalating a system failure, like the one that destroyed the first Ariane 5?
1
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
Well, we did talk about two reasons to change it earlier in the thread; did you read that part?
1
From my perspective, regardless of how people want to handle unintended overflow, explicit intended overflow for new languages and new code in older languages can reach consensus. For signed in C it's barely even a discussion since you can't rely on it while being portable.
1
1
If you want portable signed overflow, you *already* have to define functions for it, which can use __builtin_mul_overflow when available (add/sub is trivial anyway) and otherwise implement it by hand. GCC -fwrapv is also notably not complete and not a good idea to rely on too.
Should only use -fwrapv as a way of slightly hardening code with GCC. For Clang, it actually works properly, and you could use it as a language extension where signed overflow always wraps, but I don't think that's a good approach vs. marking intended overflows anyway.
This is probably not a viable solution to using wrapping types just due to the amount of noise it adds to your code
1
It's noisy, but C doesn't support custom arithmetic types like Rust. Swift has wrapping operators. Wrapping is only commonly used for unsigned integers though. It's rarely ever wanted for signed integers, and is mostly a quirk of hardware rather than something actually used.
1
2
Show replies