Hacker News Reader

Comment by abainbridge | Hacker News Reader

With this machine I propose, that requires 4-byte alignment for int32_t, then even if I wrote the code in assembly, I'd just get a unaligned access fault from the hardware. So my code still wouldn't work. I'd rather the spec was changed to reflect this reality. Instead of calling it undefined behaviour, it should say something more specific, like, "dereferencing a pointer that isn't correctly aligned may cause your program to abort".

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.

View on HN

> it should say something more specific, like, "dereferencing a pointer that isn't correctly aligned may cause your program to abort"

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'.

> 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.

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.

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.

Reply on news.ycombinator.com