5 ms·

> 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

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

chrisseaton 6y ago
> 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.
- abainbridge 6y ago
  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.
  - chrisseaton 6y ago
    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.
    - deleted 6y ago
      [deleted]
- dooglius 6y ago
  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`?
  - chrisseaton 6y ago
    > 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.

chrisseaton 6y ago

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

abainbridge 6y ago
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.
- chrisseaton 6y ago
  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.
  - deleted 6y ago
    [deleted]
dooglius 6y ago
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`?
- chrisseaton 6y ago
  > 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.