<div dir="ltr">The corresponding line does not exist, and it is in fact, wrong :)<div><br></div><div>C11 says nothing like that.</div><div>C++14 says:</div><div>"The lifetime of an object of type T begins when:</div><div>— storage with the proper alignment and size for type T is obtained, and — if the object has non-trivial initialization, its initialization is complete.</div><div>The lifetime of an object of type T ends when:</div><div>— if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or</div><div>— the storage which the object occupies is reused or released."</div><div><br></div><div>it also says:<br>"If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if:</div><div>...</div><div>a bunch of conditions".</div><div><br></div><div>Which makes it even worse because they become aliasing again.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 5:09 PM, Flamedoge via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't know when this was added on cppreference but <br><br>> <span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px">The behavior is undefined if after </span><code style="color:rgb(0,0,0);font-size:12.8px;font-family:dejavusansmono,"dejavu sans mono",courier,monospace">free()</code><span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px"> returns, an access is made through the pointer </span><code style="color:rgb(0,0,0);font-size:12.8px;font-family:dejavusansmono,"dejavu sans mono",courier,monospace">ptr</code><span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px"> (unless another allocation function happened to result in a pointer value equal to </span><code style="color:rgb(0,0,0);font-size:12.8px;font-family:dejavusansmono,"dejavu sans mono",courier,monospace">ptr</code><span style="color:rgb(0,0,0);font-family:dejavusans,"dejavu sans",arial,sans-serif;font-size:12.8px">)<br><br>This seems to suggest that there is no UB... However, I couldn't find the corresponding line or relevant part on latest C std, </span><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px"><a href="http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf" target="_blank">http://www.open-std.org/<wbr>jtc1/sc22/WG14/www/docs/n1570.<wbr>pdf</a></span></font><div><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px">Regards,</span></font></div><div><font color="#000000" face="dejavusans, dejavu sans, arial, sans-serif"><span style="font-size:12.8px">Kevin</span></font></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 4:27 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.<wbr>com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kevin,<br>
<span><br>
On April 11, 2017 at 4:14:14 PM, Flamedoge (<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>) wrote:<br>
> So only "non-freed" malloc pointers are No-Alias which makes it<br>
> flow-sensitive. There is no reason why malloc couldn't return previously<br>
> freed location.<br>
<br>
</span>Yes.<br>
<br>
Talking to Nick Lewycky on IRC, I figured out a shorter way of saying<br>
what I wanted to say.  We know that programs like this are UB in C:<br>
<br>
p0 = malloc();<br>
free(p0);<br>
p1 = malloc();<br>
if (p0 == p1) {<br>
  int v = *p0; // Semantically free'ed but bitwise equal to an allocated value<br>
}<br>
<br>
and we relied on them having UB when marking malloc's return value as noalias.<br>
<br>
However, we can end up in cases like the above by applying<br>
loop-unswitch + GVN to well defined C programs.<br>
<span class="m_5477390877775861779HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>