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

2026-01-25

2744. Multiple objects of the same type at the same address

(From thread beginning here.)

Consider:

  #include <new>

  struct A { unsigned char buf[1]; };
  static_assert(sizeof(A) == 1); // A can fit within A::buf

  int main()
  {
    A x{};
    new (x.buf) A{};
  }

A::buf provides storage for another A object. Thus, there are now two objects of type A within lifetime, which is inconsistent with the goal expressed by 6.8.2 [intro.object] paragraph 9.

Suggested resolution [SUPERSEDED]:

Change in 6.8.2 [intro.object] paragraph 3 as follows:

If a complete object of type T is created (7.6.2.8 [expr.new]) in storage associated with another object e of type “array of N unsigned char” or of type “array of N std::byte” (17.2.1 [cstddef.syn]), that array provides storage for the created object if:

• the lifetime of e has begun and not ended, and
• the storage for the new object fits entirely within e, and
• e is not and is not nested within an object of type similar (7.3.6 [conv.qual]) to T that is within its lifetime, and
• there is no array object that satisfies these constraints nested within e.

Additional notes (CWG 2026-01-23):

  A x{}: // implicit object creation for x.buf
  A* p = reinterpret_cast<A*>(x.buf); // nailed down A at x.buf

There is no pointer interconvertibility between x.buf and x, so there must be a second A at x.buf.

  struct S {
    unsigned char c[1];
  };
  unsigned char a[sizeof(S)];
  S* ps = new (a) S;  // must create S inside a buffer; now we have two "array of unsigned char" at the same address

  struct B {};
  struct A : B {};
  struct C : B {};
  struct D : A, C { unsigned char x[2]; };

  D d;
  new (d.x+1) C();

The A and C base classes must have different offsets (because their B bases must have different offsets), thus #2 creates a C object at the offset of the existing C base class object.

CWG leaned towards adding a targeted exception that two objects of the same type may be located at the same address if both are nested within the same complete object.

Possible resolution (2026-01-23):

Change in 6.8.2 [intro.object] paragraph 10 as follows:

... Two objects with overlapping lifetimes that are not bit-fields may have the same address if

• one is nested within the other,
• they are both nested within some complete object o, exactly one is a subobject of o, and the subobject is of zero size,
• they are both subobjects of the same complete object, at least one is a subobject of zero size, and they are not of similar types (7.3.6 [conv.qual]), or
• they are both potentially non-unique objects;

otherwise, they have distinct addresses and occupy disjoint bytes of storage. [ Footnote: ... ]