<div dir="ltr">On Sun, Jul 28, 2013 at 11:30 PM, Gabriel Dos Reis <span dir="ltr">&lt;<a href="mailto:gdr@cs.tamu.edu" target="_blank">gdr@cs.tamu.edu</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Richard Smith &lt;<a href="mailto:richardsmith@google.com">richardsmith@google.com</a>&gt; writes:<br>
<br>
| On Sun, Jul 28, 2013 at 10:42 AM, Nevin Liber &lt;<a href="mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt;<br>
| wrote:<br>
|<br>
|     On 28 July 2013 11:44, Gabriel Dos Reis &lt;<a href="mailto:gdr@cs.tamu.edu">gdr@cs.tamu.edu</a>&gt; wrote:<br>
|<br>
|<br>
|<br>
|<br>
|         We shouldn&#39;t be doing anything in rash.<br>
|<br>
|<br>
|<br>
|     Who is arguing for a rash decision?  This sounds like a straw man<br>
|     to me.<br>
|<br>
|<br>
|     As far as I can tell, we are exploring how to meet this very real<br>
|     need of programs (efficiently turning a buffer of raw data into<br>
|     something which has structure), which is currently being met<br>
|     (either accidentally or deliberately) by relying on certain<br>
|     undefined behavior not being undefined in any practical sense.<br>
|<br>
|<br>
| FWIW, I don&#39;t agree that such code necessarily has undefined behavior.<br>
<br>
</div>In this discussion, there are several sources of undefined behavior.<br>
<br>
The general operation model is that unless you find rules that describe<br>
the behavior of the program, it is undefined.</blockquote><div><br></div><div>Absolutely; I was trying to demonstrate the rules which I claim can be interpreted as giving this example defined behavior in the rest of my message.</div>
<div><br></div><div>Identifying differences of opinion on the meaning of the standard seems like an important activity here: they create a grey area between programmers and implementors, where there is disagreement on the definedness of programs. Both sides tend to wander into this grey area, so exploring it and clarifying the standard seems like an important function of this SG (indeed, I think this should be our primary goal).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
| Consider this ugly code, which is the kind of thing people have been<br>
| writing for years:<br>
|<br>
| ALIGNED(16) char buffer[BUFFER_SIZE];<br>
| size_t buffer_pos, buffer_read;<br>
|<br>
| T *get_from_network() {<br>
|   if (buffer_pos + sizeof(T) &lt; buffer_read) read_more_into_buffer<br>
| (sizeof(T));<br>
|   assert(is_suitably_aligned_for&lt;T&gt;(buffer+buffer_pos));<br>
|   return (T*)buffer[buffer_pos];<br>
<br>
</div>[...] I suspect you meant something like<br>
<br>
   (T*)(buffer + buffer_pos);<br></blockquote><div><br></div><div>Yes, I did, thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but even that isn&#39;t using the putative object in the storage &quot;buffer&quot; in<br>
any way.  Since casting between pointers to data in any arbitrary order<br>
is allowed, we can&#39;t take the point of cast itself as defining the<br>
beginning of the object&#39;s lifetime.</blockquote><div><br></div><div>That was not what I was suggesting: my claim was that the lifetime of the object started *before* the data was copied into it. [basic.life]p1 explicitly permits allocating an appropriately-sized-and-aligned buffer of characters and using it to store an object (without calling a constructor or using placement new).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
| }<br>
|<br>
| Now, [basic.life]p1 says that, unless the object has non-trivial<br>
| initialization, its lifetime begins &quot;when storage with the proper<br>
| alignment and size for type T is obtained&quot;. The wording here is<br>
| circular, because we don&#39;t know whether an object is being initialized<br>
| until we know whether its lifetime begins, and vice versa, but it can<br>
| be argued that the lifetime of a T object began *before* the data was<br>
| copied into the buffer, because storage with suitable size and<br>
| alignment was obtained before that point.<br>
<br>
</div>I don&#39;t see the circularity.<br>
<div class="im"><br>
|<br>
| More generally, my view of how the lifetime rules in [basic.life]p1<br>
| are intended to work is:<br>
|  * If there exists a set of times when objects&#39; lifetimes begin and<br>
| end, and that set gives the program defined behavior, then the program<br>
| has defined behavior<br>
|  * Otherwise, the program has undefined behavior<br>
<br>
</div>That view may be a novel interpretation of the standards, but I can&#39;t<br>
see the paragraph you quote supporting that, nor any other disposition,<br>
nor does it correspond to any existing interpretation I am aware of.<br></blockquote><div><br></div><div>The standard says that the lifetime of an object begins &quot;when storage with the proper alignment and size for type T is obtained&quot;. It says little about what constitutes obtaining storage ([expr.new] implies that calling an allocation function qualifies, and [basic.align]p8 suggests non-normatively that an object of type std::aligned_storage&lt;T&gt;::type qualifies). If a program takes an existing buffer and selects a subsequence of characters with the proper size and alignment (for instance, using std::align), that seems to qualify, and in practice it is very widely assumed that this does qualify as obtaining such storage.</div>
<div><br></div><div>Since the programmer is not required to make an explicit statement of the intent to start the lifetime of an object, the compiler cannot declare a program to have undefined behavior if such a statement of intent would give it defined behavior. Therefore we can conclude that the *existence* of such intent is sufficient to force the implementation to provide the desired behavior.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In fact, it is not at clear that either programmers or compilers want<br>
a notion of &#39;object resuscitation&#39;.</blockquote><div><br></div><div>I don&#39;t know what you mean by &#39;resuscitation&#39; here. Can you elaborate?</div></div></div></div>