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).
Conversation
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
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
You keep saying “broadly” and I have a feeling this word means something completely different to you than it does to me.
1
It's enabled by default in substantial portions of Android, including for lots of software that was / is developed externally. I think Android counts as something that is broadly deployed. I'm sure it's used elsewhere but that's what I work on so I'm familiar with it.
1
_FORTIFY_SOURCE is certainly broadly deployed. It's enabled by default by nearly every Linux distribution (Debian, Ubuntu, RHEL, Android - which also checks reads) and macOS. Chromium and Android also use type-based CFI for a lot of software, which is being adopted elsewhere too.
1
I mean, what else does broadly deployed mean? I would expect there's a lot more Linux software in the wild compiled with _FORTIFY_SOURCE than without it, since distributions like Debian enable it by default for their packages. Some set it as enabled in the toolchain by default.