Rust and GCC, two different ways

Rust and GCC, two different ways

When you say "what the hardware does", what hardware (and OS - some things will trap into error handlers and be turned into something by the OS) do you mean? If you mean "any hardware and platform you can reasonably run C code on", then you're advocating for the existing position, where the things that are UB in the C standard are also UB on some real hardware - e.g. division by integer zero is UB on some CPUs that run C code).

At the other extreme, you can say that it's only UB if it's also UB on the specific platform the code is running on - but note that in the past, I've used processors with errata that have UB only if the power limit on the CPU is set below a threshold. If you go to this extreme, then everything is awful; you end up with a language definition that gives you nothing portable.

So, in practice, you want to limit what's UB and what's not UB. This is something that downstream standards from C can do if there's a need; for example, POSIX C is standard C with extra restrictions (notably that CHAR_BIT is 8, and WORD_BIT is at least 32).

The fact that no-one's created a standard that's like POSIX but with more UB defined (as defining behaviour is something that still meets UB standards for the C standard) and then persuaded both compiler authors and users to accept the use of that standard is telling.