<div dir="ltr">Hello Andrea,<div><br></div><div>Thank you for the clarification. It makes a lot of sense to me. </div><div><br></div><div>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:</div><div><br></div><div><pre style="margin-top:0px;margin-bottom:1em;padding:5px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Consolas,Menlo,Monaco,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;font-size:13px;vertical-align:baseline;box-sizing:inherit;width:auto;max-height:600px;overflow:auto;background-color:rgb(239,240,241);color:rgb(36,39,41)"><code style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;line-height:inherit;font-family:Consolas,Menlo,Monaco,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;vertical-align:baseline;box-sizing:inherit;white-space:inherit">➜  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</code></pre></div><div><br></div><div>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? </div><div><br></div><div>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.</div><div><br></div><div><pre style="margin-top:0px;margin-bottom:1em;padding:5px;border:0px;font-variant-numeric:inherit;font-variant-east-asian:inherit;font-stretch:inherit;line-height:inherit;font-family:Consolas,Menlo,Monaco,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;font-size:13px;vertical-align:baseline;box-sizing:inherit;width:auto;max-height:600px;overflow:auto;background-color:rgb(239,240,241);color:rgb(36,39,41)"><code style="margin:0px;padding:0px;border:0px;font-style:inherit;font-variant:inherit;font-weight:inherit;font-stretch:inherit;line-height:inherit;font-family:Consolas,Menlo,Monaco,"Lucida Console","Liberation Mono","DejaVu Sans Mono","Bitstream Vera Sans Mono","Courier New",monospace,sans-serif;vertical-align:baseline;box-sizing:inherit;white-space:inherit">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)</code></pre></div><div><br></div><div>Sincerely,</div><div>Irene</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 21, 2018 at 9:27 AM Andrea Bocci <<a href="mailto:andrea.bocci@cern.ch">andrea.bocci@cern.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Irene,</div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>Ciao,</div><div>.Andrea<br></div></div>
</blockquote></div></div>