> The problem is that C code seems to do this all the time.
People should write these bits in assembly (as little as possible, but doing the casting and things), and then keep their C code well-defined using these low-level library routines.
People should write these bits in assembly (as little as possible, but doing the casting and things), and then keep their C code well-defined using these low-level library routines.
The key difference is that the alignment (usually) cannot be determined at compile time, so the compiler would still have to generate code that worked if the alignment was correct at run time. I think this is what many people either expect or would like the compiler to do.
With that change to the spec, I could continue to write my code in portable C, and I'd only get an abort on the target with this alignment constraint.
What if on some other machine it doesn't cause the program to abort but instead returns a broken result? How do you cover that in the spec?
> But some would argue that it is not right that GCC 7 breaks such code on a machine where that problem doesn't exist.
Right, so let's write these low-level things in C and not worry about the case of 'where the problem doesn't exist'.
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.
By checking the alignment on every access? That'd be far too expensive if the machine you're on doesn't trap.
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.
Yeah, but good luck selling that... for the reasons you've identified it'd be a nightmare to run C on it.