This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

2863. Unclear synchronization requirements for object lifetime rules

(From submission #507.)

Subclause 6.7.4 [basic.life] paragraph 6 specifies:

Before the lifetime of an object has started but after the storage which the object will occupy has been allocated [ Footnote: ... ] or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, ...

"Before" and "after" are intended to refer to the "happens before" relation (which is not a total order), but the specific use here does not properly handle evaluations racing with the start of the lifetime of an object.

Possible resolution (option 1) [SUPERSEDED]:

1. Change in 6.7.4 [basic.life] paragraph 4 as follows:

   The properties ascribed to objects and references throughout this document apply for a given object or reference only during its lifetime. [Note 2: In particular, before the lifetime of an object starts and after its lifetime ends there are significant restrictions on the use of the an object not within its lifetime, as described below, in 11.9.3 [class.base.init], and in 11.9.5 [class.cdtor]. Also, the behavior of an object under construction and destruction can differ from the behavior of an object whose lifetime has started and not ended. 11.9.3 [class.base.init] and 11.9.5 [class.cdtor] describe the behavior of an object during its periods of construction and destruction. —end note]

2. Change in 6.7.4 [basic.life] paragraph 6 as follows:

   Before the lifetime of an object has started but In an evaluation that occurs after the storage which the an object will occupy has been allocated [ Footnote: ... ] but not after the lifetime of the object has started or, in an evaluation that occurs not before after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that represents the address of the storage location where the object will be or was located may be used but only in limited ways. For an object under construction or destruction, see 11.9.5 [class.cdtor]. ...

3. Change in 6.7.4 [basic.life] paragraph 7 as follows:

   Similarly, before the lifetime of an object has started but in an evaluation that occurs after the storage which the an object will occupy has been allocated but not after the lifetime of the object has started or, in an evaluation that occurs not before after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any glvalue that refers to the original object may be used but only in limited ways. For an object under construction or destruction, see 11.9.5 [class.cdtor]. ...

4. Change in 6.7.4 [basic.life] paragraph 8 as follows:

   If, in an evaluation that occurs not before 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 the original object is transparently replaceable (see below) by the new object. ...

Proposed resolution (approved by CWG 2024-04-19) [SUPERSEDED]:

1. Change in 6.7.4 [basic.life] paragraph 4 as follows:

   The properties ascribed to objects and references throughout this document apply for a given object or reference only during its lifetime. [Note 2: In particular, before the lifetime of an object starts and after its lifetime ends there are significant restrictions on the use of the an object not within its lifetime, as described below, in 11.9.3 [class.base.init], and in 11.9.5 [class.cdtor]. Also, the behavior of an object under construction and destruction can differ from the behavior of an object whose lifetime has started and not ended. 11.9.3 [class.base.init] and 11.9.5 [class.cdtor] describe the behavior of an object during its periods of construction and destruction. —end note]

2. Add a new paragraph before 6.7.4 [basic.life] paragraph 6 as follows:

   An evaluation E is said to be in a storage-only phase of an object O if

   • E happens after the storage which O will occupy is allocated and E does not happen after the lifetime of O starts; or
   • E does not happen before the lifetime of O ends and E happens before the storage which O occupied is reused or released.

3. Change in 6.7.4 [basic.life] paragraph 6 as follows:

   Before the lifetime of an object has started but after the storage which theobject will occupy has been allocated [ Footnote: ... ] but not after the lifetime of the object has started or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, In an evaluation that is in a storage-only phase of an object, any pointer that represents the address of the storage location where the object will be or was located may be used but only in limited ways. For an object under construction or destruction, see 11.9.5 [class.cdtor]. ...

4. Change in 6.7.4 [basic.life] paragraph 7 as follows:

   Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, in an evaluation that is in a storage-only phase of an object, any glvalue that refers to the original object may be used but only in limited ways. For an object under construction or destruction, see 11.9.5 [class.cdtor]. ...

5. Change in 6.7.4 [basic.life] paragraph 8 as follows:

   If, in an evaluation that is in a storage-only phase of an object and where the evaluation does not happen before after the lifetime of an the object ends 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 the original object is transparently replaceable (see below) by the new object. ...

Additional notes (April, 2024)

Concerning the proposed change to 6.7.4 [basic.life] paragraph 8, it was noted that (for example) a common non-allocating placement new does not happen before the storage is reused.