In Rust, both signed and unsigned integer overflow is always considered a bug. Intended overflows need to be marked and it supports wrapping for both signed and unsigned via the appropriate APIs. It traps for unintended overflows in debug builds by default and can in production.
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
Rust has better support for wrapping integer arithmetic than C, since it has portable signed wrapping not requiring an opt-in compiler extension like -fwrapv. The reason it's not the default is because it's rarely intended, so it makes unintended overflows far harder to find.
1
1
The wrapping methods are rarely used. In a case where they were heavily needed, you can use types that implement the arithmetic operators as wrapping. There are very few situations where that's the case though. Standard library provides great hashing algorithms already.
Modular arithmetic is used in cryptography, and that still works just fine. It's just explicitly written to use modular arithmetic. Being explicit about this is a positive. Also, uses for modular arithmetic often don't want the mod to be based on fixed-size integer widths anyway.
1
High quality C code will do things the same way, by marking intended overflows so that -fsanitize=integer can be used to find unintended overflows. I'm not really sure what's controversial about that. Being explicit about where it's wanted has major advantages.