<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2224: Ambiguous status of access to non-live objects</title>
<meta property="og:title" content="Issue 2224: Ambiguous status of access to non-live objects">
<meta property="og:description" content="C++ library issue. Status: C++17">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2224.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#C++17">C++17</a> status.</em></p>
<h3 id="2224"><a href="lwg-defects.html#2224">2224</a>. Ambiguous status of access to non-live objects</h3>
<p><b>Section:</b> 16.4.5.10 <a href="https://wg21.link/res.on.objects">[res.on.objects]</a> <b>Status:</b> <a href="lwg-active.html#C++17">C++17</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2012-12-17 <b>Last modified:</b> 2017-09-07</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#res.on.objects">issues</a> in [res.on.objects].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++17">C++17</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The standard currently does not discuss when library objects may be accessed, except in a non-normative 
note pertaining to synchronization in [res.on.objects], leaving it ambiguous whether single-threaded 
code can access a library object during its construction or destruction. For example, there is a 
reasonable question as to what happens if the deleter supplied to a <code>unique_ptr</code> transitively 
accesses the <code>unique_ptr</code> itself during <code>unique_ptr</code>'s destruction; a straightforward 
reading suggests that this is permitted, and that the deleter will see the <code>unique_ptr</code> still 
holding the originally stored pointer, but consensus on the LWG reflector indicates this was not the 
intent (see discussion beginning with 
<a href="http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=lib&amp;msg=33362">c++std-lib-33362</a>).
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Open.
</p>
<p>
Geoffrey will provide an example that clearly highlights the issue.
</p>

<p><i>[2013-03-19 Geoffrey provides revised resolution and an example]</i></p>


<p>
I contend that the most straightforward reading of the current standard requires the following example code to print 
"good" (because <code>~unique_ptr</code> is not specified to modify the state of the internal pointer), but the consensus 
on the reflector was that its behavior should be undefined.
<p/>
This example also shows that, contrary to a comment in the telecon, the PR is not tautological. 11.9.5 <a href="https://wg21.link/class.cdtor">[class.cdtor]</a>/p4 
explicitly permits member function calls during destruction, so the behavior of this code is well-defined as far as 
the core language is concerned, despite the fact that it accesses a library object after the end of the object's 
lifetime. If we want this code to have undefined behavior, we need to specify that at the library level.
</p>

<blockquote><pre>
#include &lt;memory&gt;
#include &lt;iostream&gt;

class A;

struct B {
 std::unique_ptr&lt;A&gt; a;
};

struct A {
 B* b;
 ~A() {
   if (b-&gt;a.get() == this) {
     std::cout &lt;&lt; "good" &lt;&lt; std::endl;
   }
 }
};

int main() {
 B b;
 b.a.reset(new A);
 b.a-&gt;b = &amp;b;
}
</pre></blockquote>

<p>
Previous resolution:
</p>
<blockquote class="note">
<ol>
<li><p>Change the title of sub-clause 16.4.5.10 <a href="https://wg21.link/res.on.objects">[res.on.objects]</a> as indicated:</p>
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
</li>

<li><p>Edit 16.4.5.10 <a href="https://wg21.link/res.on.objects">[res.on.objects]</a> p2 as indicated:</p>
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor 
of any object of a class type defined in the standard library happens before any other member function 
invocation on that object and, unless otherwise specified, to ensure that completion of any member function 
invocation other than destruction on such an object happens before destruction of that object. This applies 
even to objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</del>
<ins>If an object of a standard library type is accessed outside of the object's lifetime (6.8.4 <a href="https://wg21.link/basic.life">[basic.life]</a>), 
the behavior is undefined unless otherwise specified.</ins></p>
</li>
</ol>
</blockquote>

<p><i>[2014 Urbana]</i></p>

<p>
STL: is this resolved by our change to the reeentrancy rules? [LWG <a href="lwg-active.html#2414" title="Member function reentrancy should be implementation-defined (Status: Open)">2414</a><sup><a href="https://cplusplus.github.io/LWG/issue2414" title="Latest snapshot">(i)</a></sup>]<br/>
GR: don't think that solves the multi-threaded case<br/>
MC: I like changing the note to normative text<br/>
GR: uses the magic "happens before" words, and "access" is magic too<br/>
JW: I like this. strict improvement, uses the right wording we have to say this properly<br/>
STL: I like the last sentence of the note, could we add that as a new note at the end?<br/>
So add "[Note: This applies even to objects such as mutexes intended for thread synchronization.]" to the end and move to Ready 
</p>


<p id="res-2224"><b>Proposed resolution:</b></p>
<p>This wording is relative to N3485.</p>

<ol>
<li><p>Change the title of sub-clause 16.4.5.10 <a href="https://wg21.link/res.on.objects">[res.on.objects]</a> as indicated:</p>
<p><del>Shared objects and the library</del><ins>Library object access</ins> [res.on.objects]</p>
</li>

<li><p>Edit 16.4.5.10 <a href="https://wg21.link/res.on.objects">[res.on.objects]</a> p2 as indicated: <em>[<i>Editorial remark:</i> The motivation, is to 
be more precise about the meaning of "outside the object's lifetime" in the presence of threads &mdash; <i>end editorial 
remark</i>]</em></p>
<p>-2- <del>[<i>Note</i>: In particular, the program is required to ensure that completion of the constructor 
of any object of a class type defined in the standard library happens before any other member function 
invocation on that object and, unless otherwise specified, to ensure that completion of any member function 
invocation other than destruction on such an object happens before destruction of that object. This applies 
even to objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</del>
<ins>If an object of a standard library type is accessed, and the beginning of the object's lifetime 
(6.8.4 <a href="https://wg21.link/basic.life">[basic.life]</a>) does not happen before the access, or the access does not happen before the end 
of the object's lifetime, the behavior is undefined unless otherwise specified. [<i>Note</i>: This applies even to 
objects such as mutexes intended for thread synchronization. &mdash; <i>end note</i>]</ins></p>
</li>
</ol>






</body>
</html>
