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.
Conversation
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
It is a big deal, because it would start on the path towards making signed integer overflow as hard to enable as unsigned integer overflow. The current definition of the standard makes it far easier, and therefore makes C into a safer language when the implementation wants that.
1
Trapping on signed integer overflow isn't a new behavior. It has been around as a compiler feature for ages and is broadly deployed. Trapping on unsigned integer overflow is a newer feature, and it's far harder to deploy largely due to it not being standards compliant.
2
Signed integer overflow is always a bug (unless -fwrapv is passed, which isn't portable), so it can reported and fixed as a bug in software. It's also detected by default by tools like UBSan designed to catch UB. Since unsigned overflow is well-defined, that makes it harder.
1
Even with -fwrapv, most signed integers overflow is still a bug. Wrapping binds how bad things get, sometimes. But it can still get pretty bad!
1
2
Yeah, definitely. It's quite rare for -fwrapv to actually make a difference anyway. It's unfortunate if projects depend on it and decide not to avoid signed overflow or at least mark intended overflows with the intrinsics. It makes it way harder to find the bugs or harden it.
1
1
It's good to pass it as a default (if you aren't enabling overflow checks) but having an intentional hard dependency on it is different, especially since it doesn't fully work in GCC. There are usually far less signed overflows and fixes can be upstreamed.
1
1
Ideally projects would mark the intended unsigned overflows (with a wrapper around the intrinsic) to enable using that sanitizer too but it's harder to make that argument since the intentional ones aren't bugs. Majority aren't intended though, and nice to find or mitigate them.
I do have an hour long talk on the topic of signed integer overflow. Getting it through C, C++, what code looks like, how it compiles, bugs, etc.
youtu.be/JhUxIVf1qok
3