[cfe-dev] Understand assumptions towards uninitialized variables on stack

[David Blaikie via cfe-dev]

One particular point is: "In contrast, for -O0 the return value seems
un-predictable. "

Not entirely true - and if you were writing this code to intentionally get
a unpredictable value (to seed a random number generator etc) - that's a
security problem (has been a bug in crypto libraries etc where they've used
similar techniques and eventually the compiler breaks them - or people find
ways to compromise the source of the data (by writing specific values to
stack variables elsewhere in the program making the values more predictable)

On Wed, Nov 21, 2018, 10:03 AM via cfe-dev <cfe-dev at lists.llvm.org wrote:

> > IMHO the inconsistency makes a lot of additional effort and perhaps is
> > not preferred, but I guess that's eventually the programmer's
> > responsibility to solve that?
>
> Correct. The program has undefined behavior, and it is the programmer's
> responsibility to solve that.  The Undefined Behavior Sanitizer would
> reveal the problem immediately.
>
> > uninitialized variables on the stack is assumed to be zero due to
> > some reason,
>
> That is not exactly what happened.  The assignment is from uninitialized
> memory, which will have an unknown value.  Because the value is unknown,
> the assignment can be optimized to avoid a read from memory, and
> substitute any convenient value, without perturbing any defined property
> of the program. The most convenient value to use here is zero.
>
> This is a different sequence of reasoning than what you suggested, which
> is more like this:  The stack values are assumed to be zero, therefore
> we can use value propagation to assign the value zero instead of reading
> memory with a known value.
>
> I agree that the net effect here is the same, but the reasoning is
> important for correct understanding of the program's semantics.
> --paulr
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181121/db2d3365/attachment.html>