Now I agree, your average webapp won't see any benefit by removing checks and will see security features by keeping them in, so I'm all for it.
But in OSs (or browsers), speed does matter. And there's no way to optimize it (every + or array operation involves an if).
Is this just one of the "costs of doing business"?
In Rust, the operators check in debug builds, and wrap in release builds. Calls are provided so you can always have them check, or always have them wrap, if you need it.
Note that C has some really ugly behavior here. Signed overflow is undefined behavior, which means that the compiler doesn't need to check for it, but also that it can assume it never happens and optimized based on that. Many programmers don't realize this, or don't notice that they've accidentally written code that depends on overflow behavior, which can lead to many entertaining bugs: https://lwn.net/Articles/511259/
That's because different CPUs behave differently. To avoid undefined behavior, you have to have an "if" at every +.
That said, rolling over on a signed integer is almost always an error, although luckily it is usually one of the easier ones to detect in the debugger. Big negative numbers are a dead giveaway.
The danger is
signed int x; cin>>x; if(x+1<x){return OVERFLOW;}
will, in modern optimizing compilers, never return OVERFLOW
There were quite a few security holes introduced by the compiler with that.
-----
The only problem is to make a standard, one has to define that MAX_INT+1 = 0 or something. Then, whenever one does
signed int x;
cin>> x;
signed int y = x+1;
really turns into
signed int = 0;
if ( x < MAX_INT)
y= x+1
else
y = 1;
( bangs head with ball-peen hammer; rends garment )
Not entirely clear that such an operator is ever what you really want, I suppose...
If you want to overflow there are special types that you can use.
Rust has a feature called "debug assertions". This is a compile-time option to configure, well, debug assertions.
Rust-the-language says that when debug assertions are turned on, overflow checks must be in place, and will panic. When debug assertions are not on, overflow is considered a "program error", and while implementations are not required to do the check, they may. if they do not, they must implement two's compliment wrapping.
rustc currently does not check when debug assertions are off.
Cargo has the concept of "build profiles", and there are a number of different ones. By default, "cargo build" executes a "debug profile" build, which, by default, has debug assertions on. "cargo build --release" executes a "release profile" build, which, by default, as debug assertions off.
If you want wrapping behavior, use https://doc.rust-lang.org/stable/std/num/struct.Wrapping.htm...
Just like languages older than C did, by providing the option to explicitly request to disable safety checks.
For example in ESPOL and NEWP (1961), running unsafe modules requires admin permission, user code cannot make use of unsafe. Something like setuid in UNIX.
You don't need 100% unsafe code, rather write it in a safe way, profile it, and then only on the sections that really matter you might turn those checks off, after trying everything else to optimize it.
You figure out if you need to optimize by testing and benchmarking.