12 juin 2021 16:49 "Tom Honermann via Std-Proposals" <std-proposals@lists.isocpp.org> a écrit:

In either case, I think there is a need to be able to propagate poison/taint.

I know it might sound dump, but, like what we do with the nullptr keyword, wouldn't a new keyword, like "undefined" for instance, be the best solution for that?
If a variable has this pseudo-value, it means to the compiler that it is uninitialized, and appropriate warnings can be fired if the compiler can prove a variable with the "undefined" value is being used.
It would only have effects during compilation, and would be completely "removed" during runtime.

What do you think?

As Ville mentioned, that has been suggested before.  I don't know if a paper has been submitted for that approach.

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.

Tom.

Antoine Viallon