Re:The Git source code audit, viewed as a Rust programmer
by jeroenhd on Tuesday January 24, 2023 @12:29PM
(#34506886)
I agree from a language standpoint but trapping overflows by default would be quite costly. If you get the branch predictor involved with every addition or multiplication then you'll very quickly slow down your program, especially in the hot code paths. I think most general purpose programs don't run into overflow anymore these days, and the performance benefit probably outweighs the safety for most people.
[ Parent
| on HN ]
Re:The Git source code audit, viewed as a Rust programmer
by cerved on Tuesday January 24, 2023 @04:35PM
(#34510794)
I think the opposite is true, most software projects benefit from safety and not performance
Re:The Git source code audit, viewed as a Rust programmer
by throwaway81523 on Wednesday January 25, 2023 @04:06AM
(#34516116)
Most programs should be written in HLL's with unbounded integers and garbage collection. There are a few programs that need machine arithmetic and manual memory management, for performance or whatever reasons, and Rust is intended to allow writing those programs safely. So it seems like a mistake to not treat int overflow as a serious error.
Idk if branch prediction or whatever would have to be involved. Most architectures will already trap on divide by zero or things like that, and will set a condition code for int overflow. Making the condition code sticky like it is for IEEE floating point arithmetic would allow doing a software trap once a basic block finished. It is a shame that the current trendy architecture (Risc-V) goes the opposite way and has no condition codes at all.