On Sat, 12 Jun 2021, 20:13 Antoine Viallon via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

>
>
> 12 juin 2021 16:49 "Tom Honermann via Std-Proposals" <
> std-proposals_at_[hidden]
> <std-proposals_at_[hidden]?to=%22Tom%20Honermann%20via%20Std-Proposals%22%20%3Cstd-proposals_at_[hidden]%3E>>
> 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?
>

What does it mean to prove that an uninitialized value is used? There may
be some input on which the value will be used, but the program may be part
of a larger system which guarantees that input is not encountered.

Actually, we want runtime effects; at least 3 distinct effects. In secure
mode, we want a specific value to be loaded in place of the uninitialized
value; in debug mode, the program should terminate with a runtime
diagnostic; in release mode we want the optimizer to assume that use of the
uninitialized value cannot occur.



> Antoine Viallon
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>