On 6/12/21 3:12 PM, Antoine Viallon via Std-Proposals wrote:
>
>
> 12 juin 2021 16:49 "Tom Honermann via Std-Proposals"
> <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]?to=%22Tom%20Honermann%20via%20Std-Proposals%22%20<std-proposals_at_[hidden]>>>
> 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
>