> How do you cover that in the spec?

OK, how about, "dereferencing a pointer that isn't correctly aligned doesn't work on some hardware". I see that this is a hard area for the spec to do well. But the current situation isn't viable. I can't tell whether I can safely use fread for heavens sake.

I feel like dereferencing an incorrectly aligned pointer could be a runtime error, just like divide by zero or accessing memory that doesn't exist. Maybe that would be an improvement from the current status. Although I'm not sure the spec _could_ be changed like this at this point in time.

> I feel like dereferencing an incorrectly aligned pointer could be a runtime error

By checking the alignment on every access? That'd be far too expensive if the machine you're on doesn't trap.

You could come up with hardware that does this for any aspect of the spec though. For instance, I could make an ISA whose ADD instruction was normal except that 2+2=5. Adding a check around each add instruction would certainly be very expensive. Does the existence of this mean that we should redefine addition (on _all_ hardware) to avoid the penalty? Would compilers for other architectures be justified in eliding `if(x+y==z) foo();` if it can prove that `x` and `y` are `2`?

> For instance, I could make an ISA whose ADD instruction was normal except that 2+2=5.

Yeah, but good luck selling that... for the reasons you've identified it'd be a nightmare to run C on it.

No. Letting the hardware just do its thing. Like an out of bounds memory access or divide by zero.

Editing here because it looks like we've hit the max reply depth. This wouldn't be like UB in the same way that code that could generate an out-of-bounds memory accesses is not UB. The critical thing is that the compiler should assume that the hardware error does not occur.

But how would that be different to UB? If you let the hardware do whatever it wants that's no different to UB doing whatever it wants.