Forbidding trapping also breaks widely deployed existing implementations, so you can't do that either per your own rules, sorry.
Conversation
This Tweet was deleted by the Tweet author. Learn more
It's always implemented in software via hardware features. The features vary in performance. Jump-on-overflow is a lot worse than architectures with support for enabling a trapping mode, whether it's strict or propagates a poison value that can never be accessed (since it traps).
1
1
Hardware doesn't implement C, so there isn't a standard behavior defined by hardware. It's up to the compiler to map C onto the hardware or the virtual machine. They get to choose how to handle each kind of undefined or implementation defined behavior, and everything else.
2
1
I think you're getting hung up on this idea that if the spec doesn't leave something undefined, then implementations can't *ever* deviate from what otherwise would be defined. It just means that they can't deviate by default. You can pass flags that change behavior.
1
No, that's not what I've been saying. I think it would be a serious regression to break compatibility with safe implementations by making it correct to be incompatible with them. You want to massively roll back safety and security, especially if you want to remove it by default.
2
1
It's not a big deal if the spec says that overflow wraps. Anyway, a most useful version of trap-on-overflow would do this for unsigned, which isn't allowed in the current spec. It's fine to have security technologies that create interesting new behaviors.
2
The "breaking interface contracts is a security enhancement" view is a very very harmful one. It's the opposite.
3
7
Having to cast to unsigned just to get the behavior that the CPU supports makes code messier and harder to maintain, which only leads to more security vulnerabilities.
1
It's extremely rare to have a real use case for signed overflow, unlike unsigned. You certainly don't need to open code anything when you need it. Even for unsigned, the vast majority of overflows in the real world are not intended and it's not hard to mark the intended cases.
1
For the extremely rare cases that you actually need it, it's not the end of the world to do it with functions like mul32(a, b). For Clang and GCC, these can use __builtin_mul_overflow with a fallback elsewhere. By the way, in GCC, -fwrapv isn't fully implemented so it's not safe.