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

[div code via cfe-dev]

Hello Andrea,

Thank you for the clarification. It makes a lot of sense to me.

On the other hand, I am trying to understand the "inconsistency" regarding
different optimization levels, with respect to this undefined behaviour. So
basically this is how I executed the presented code on my machine:

➜  code clang-5.0 -g -O0 test.c
➜  code ./a.out
➜  code echo $?
192
➜  code clang-5.0 -g -O2 test.c
➜  code ./a.out
➜  code echo $?
0
➜  code


So for the -O2 case since t is zeroed, the return value will be zero in
anyway. In contrast, for -O0 the return value seems un-predictable. 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?

Overall, from the assembly code generated from clang -O2 (attached below),
uninitialized variables on the stack is assumed to be zero due to some
reason, and I am writing to inquire the motivation/analysis behind.

0000000000400490 <main>:
  400490:       31 c0                   xor    %eax,%eax
  400492:       c3                      retq
  400493:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  40049a:       00 00 00
  40049d:       0f 1f 00                nopl   (%rax)


Sincerely,
Irene

On Wed, Nov 21, 2018 at 9:27 AM Andrea Bocci <andrea.bocci at cern.ch> wrote:

> Hi Irene,
> I am not an expert, but here is my interpretation: "undefined behaviour"
> means that the behaviour observed by the person running the compiled
> program is not dictated by the C++ standard, and thus the compiler is free
> to do whatever it wants.
>
> Setting the value of an uninitialised variable to zero, or to any
> arbitrary number, or to a random number, or not setting it at all, would be
> acceptable behaviours for "undefined behaviour".
>
> Ciao,
> .Andrea
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181121/081bff7e/attachment.html>