<div dir="ltr">A small note:<br><div><br></div><div><font size="4">Definitions<br></font></div>The C11 draft (or whatever I found; <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf" target="_blank">link</a>) says it is the "use" of the uninitialized value:<br><br>Under the <b>Undefined</b> Behavior section:<br>i) "- The value of an object with automatic storage duration is used while it is indeterminate" (see indeterminate value later)<br><div><br></div><div><div>Where indeterminate value is defined as "either an unspecified value or a trap representation"...</div><div><br></div></div>On the other hand, at the definition of the term "Unspecified behavior", the following is the definition:<br>ii) "<b>unspecified</b> behavior: use of an unspecified value, or other behavior [...]"<br><div><br></div><div><font size="4">Consequences?</font><br></div><div><br></div><div>It
 seems to me that these two statements/definitions (i) and (ii) 
contradict each other, however, neither one is stricter than the other 
one...</div><div><br></div><div>So, we use an object. It can be <i>with</i> or <i>without</i>
 automatic storage duration. The object can hold unspecified value or 
can be a trap representation. The question is, using the value is <b>unspecified</b> or <b>undefined</b>?<br></div><div><br></div><div>1) Based on this: the behavior is <b>unspecified</b>, if the object "used" is <i>without</i> automatic storage duration.</div><div><br></div><div>2) The value is <b>undefined</b>, if an object is "used" <i>with</i> automatic storage duration, which has a trap representation.</div><div><br></div><div>So, if I understand correctly, an object <i>with</i>
 automatic storage duration has an unspecified value before the first 
modification (I've yet to find an explicit statement of this, however, 
it seems reasonable...). Which of the two contradicting statements 
holds? Is it <b>unspecified</b> or <b>undefined</b>?<font color="#888888"><br></font></div><font color="#888888"><br><div>László</div></font></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 14, 2020 at 6:48 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 9/14/20 9:30 AM, James Y Knight via llvm-dev wrote:<br>
> On Mon, Sep 14, 2020 at 3:19 AM László Radnai via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
>> A problem arises, and I am not sure if it is really a problem or just<br>
>> weird C-compliant behavior.<br>
>><br>
>> int a; // or, equally, int a=0;<br>
>><br>
>> int main(){<br>
>>   int b;<br>
>>   if (b) // (*)<br>
>><br>
> At this line, you invoke undefined behavior by reading the value of "b",<br>
> before it's been initialized. At this point, the compiler may do whatever<br>
> it likes.<br>
<br>
FTR, it is *not* UB to read the value of b, you will read undef which is <br>
totally fine. It is however UB to branch on undef.<br>
At that point we can stop discussing what "happens next".<br>
<br>
~ Johannes<br>
<br>
<br>
<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>