3 ms·
Undefined behaviour isn't an option for Safe Rust, where the impossibility of invoking undefined behaviour is the whole point. Non-deterministic unspecified val
by MaxBarraclough 6y ago
Undefined behaviour isn't an option for Safe Rust, where the impossibility of invoking undefined behaviour is the whole point. Non-deterministic unspecified values aren't in keeping with the Safe Rust philosophy either.
I imagine throw-on-overflow is slower than wrap-on-overflow.
C# can be configured to throw an exception when an int is overflowed, [0] but this behaviour isn't the default and is rarely used (typically it uses wrap-on-overflow). I imagine it might have a significant performance impact, but I'm not sure.
In a language like SPARK Ada, intended for formal verification, you can insist upon a rigorous proof that unintended overflow can never occur. That isn't an option for Safe Rust, at least not without significant breakthroughs in tooling.
[0] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/checked-and-unchecked https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- bluGill 6y agoPerhaps, but I often know via information not available to the compiler (it might be to a SPARK proof) that overflow won't happen and I don't want to check for it.
- deleted 6y ago[deleted]
- nicoburns 6y agoThat option's available in Rust on a per opration basis if you want it, it's just not the default
- MaxBarraclough 6y agoProgrammers can't be trusted to do this kind of free-form reasoning correctly, as attested by the unending stream of security vulnerabilities arising from undefined behaviour in C and C++ codebases. The push for safe languages is motivated by pragmatism, not theoretical purity.
- bluGill 6y agoThe push back that performance matters in the real world still exists. I want a secure language, but I don't have enough spare CPU for some
- MaxBarraclough 6y agoThe performance of modern Rust is competitive with C++.
- bluGill 6y agoWhich is why I told my boss I want some time to play with rust to see how it works in our real world.
- renox 6y ago> I imagine it might have a significant performance impact, It depends on the CPU: MIPS has(had if you consider MIPS dead) some integer operations which trapped in case of integer overflow AFAIK the 'trapping operations' were as fast as the non-trapping operations (when no overflow occurred of course). Unfortunately even though RISC-V is MIPS successor, it doesn't have those trapping operations :-( I must admit I don't understand why no modern CPU ISA has these trapping instructions: explicit checks have an 'instruction cache cost', so users won't enable them which reduces security..