On Sun, 13 Jun 2021 at 16:07, Tom Honermann via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> Compilers could warn on use of a poisoned value subject to their analysis limitations. Consider this example:
>
> void f(bool b1, bool b2) {
> int *x = POISON(nullptr);
> if (b1) {
> x = find_x();
> }
> if (b2) {
> use_x(*x);
> }
> }
>
> A defect is present if f() is called with b1 false and b2 true. A compiler could warn about the existence of an execution path that results in use of the poisoned value, but such warnings will be false positives (FPs) if f() has a contract that b2 may only be true if b1 is also true. Static analysis tools can do better by examining an entire program to determine if there is a call to f() with b1 false and b2 true, but such analysis is not necessarily conclusive since the values of b1 and b2 may derive from run-time input; in which case, issuing warnings will result in some FPs, and not issuing them will result in some false negatives (FNs). A run-time tool can potentially perfectly identify such defects by tracking undefined/poisoned values and observing their use.
>
> I think Edward had it right in his response about desiring potentially distinct behavior for secure, debug, and release compilation modes.

Intriguing. That makes this kinda like a contract assertion, but
instead of saying "if we come here, the value of x must be so-and-so",
it's saying "wherever we go, value of x must be so-and-so", and more
specifically, "wherever we go, if x is used, its value must
not be this value". There might be a general notion lurking here.