[steveklabnik]

Rust traps on overflow in debug mode, and does two’s compliment overflow in release mode. You can turn the traps on in release if you wish, but the cost is deemed too expensive to do so by default, especially when bounds are always checked, so it isn’t as severe of an issue in Rust.

[codedokode]

This becomes a vicious circle. Language developers do not want to make the language safer because legacy CPUs do not support overflow trapping, and CPU designers do not bother to add it because nobody needs it. For example, RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.

[snvzz]

>RISC-V spec says that they decided to not add overflow trapping because it is "easy" to do in 3 or 4 existing instructions.

It is not just "easy" to do, but actually easy to do, without quotes.

And much, much easier than as an exception/trap.

And it is explicit, which makes it even better. No hidden behaviour.

[Joker_vD]

What about execution speed? I find it somewhat hard to believe that adding 2/3 additional arithmetic instructions plus a branch to every addition/subtraction would perform better than having the (I believe quite small) circuitry after the ALU (probably still on the critical path) that detects carry-out/overflow and triggers a trap.

> it is explicit, which makes it even better. No hidden behaviour.

Which is why we do virtual address translation and populate (and evict!) L1/L2 caches in software, and the reason why CHERI project is misguided.

[codedokode]

They made a choice that safe addition takes 3-4 instructions, and wrapping one (rarely used except for cryptography) takes 1 instruction. Doesn't it make more sense to make often-needed safe addition 1 instruction and rarely needed one to take 3-4 instructions?