What is the meaning of use(*p) in case p is null? what should the compiler emit?
Re:Undefined behavior in C is a reading error
by a1369209993 on Friday May 21, 2021 @01:45PM
(#27237348)
> What is the meaning of use(*p) in case p is null?
It dereferences a null pointer, invoking undefined behaviour, then calls the function `use` with the resulting value.
> what should the compiler emit?
Probably something to the effect of:
ld r0 [sp+.p] # if p is not already in a register
ld r0 [r0] # *p
jsr use
but it would be fine to emit something like: ld r0 [sp+.p] # if p is not already in a register
jz r0 .panic
ld r0 [r0] # *p
jsr use
because the jz can only be taken when undefined behaviour happens.
Re:Undefined behavior in C is a reading error
by leosarev on Friday May 21, 2021 @01:33PM
(#27237148)
If p is statically null, it should emit compile time error.
If not, it should emit machine instruction to deference p.
Re:Undefined behavior in C is a reading error
by tom_mellior on Friday May 21, 2021 @03:42PM
(#27238944)
In all of the examples above it will emit a machine instruction to dereference p. What your grandparent is complaining about is that it will later remove an "if (!p)" test.
Not further. Anywhere. If the implementation wishes to rewrite pointer dereferences from `use(*p)` to:
it may do so (undefined behaviour!), but if it chooses not to do so, it may not later pretend that it did, and remove a explict `if(!p)` that the programmer wrote. Given: this is fine: but not: The implementation can optimize based on information (like "p is not null") that is actually true (even if that's because it made it true), but not based on information it assumed was true on the basis that it counterfactually could have made it true (but didn't).> it would prevent many classes of branch pruning.
Yes, that's the general idea.