4 ms·

> Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour. I'm

by hnjst 5y ago

> Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour. I'm not completely sure I understand that correctly, but do you mean that statements that are constant unless considering a possible (and "credible"?) implementation of UB shouldn't be fair-game for the compiler to optimize out? EDIT: I think I see a more tricky case that may be one of those you're referring to. Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. I can relate with that but I suspect that it would prevent many classes of branch pruning. I get what you suggest while describing malicious compliance but I can imagine that it could be a false impression resulting from trade-offs that favor optimization opportunities to "out-of-spec but canonical/natural" implementations.

a1369209993 5y ago
> Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. Not further. Anywhere. If the implementation wishes to rewrite pointer dereferences from `use(*p)` to: if(!p) abort(); use(*p); 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: use(*p); if(!p) return NOPE; this is fine: if(!p) abort(); use(*p); //if(!p) return NOPE; // unreachable because of if, not because of use but not: use(*p); //if(!p) return NOPE; // CVE-20XX-XXXXX 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.
- junke 5y ago
  What is the meaning of use(*p) in case p is null? what should the compiler emit?
  - leosarev 5y ago
    If p is statically null, it should emit compile time error. If not, it should emit machine instruction to deference p.
    - tom_mellior 5y ago
      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.
  - a1369209993 5y ago
    > 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.
    - deleted 5y ago
      [deleted]

by hnjst 5y ago

a1369209993 5y ago

> Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. Not further. Anywhere. If the implementation wishes to rewrite pointer dereferences from `use(*p)` to: if(!p) abort(); use(*p); 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: use(*p); if(!p) return NOPE; this is fine: if(!p) abort(); use(*p); //if(!p) return NOPE; // unreachable because of if, not because of use but not: use(*p); //if(!p) return NOPE; // CVE-20XX-XXXXX 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.

junke 5y ago
What is the meaning of use(*p) in case p is null? what should the compiler emit?
- leosarev 5y ago
  If p is statically null, it should emit compile time error. If not, it should emit machine instruction to deference p.
  - tom_mellior 5y ago
    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.
- a1369209993 5y ago
  > 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.
  - deleted 5y ago
    [deleted]