CWG2719 [expr.new] Is placement-newing an object at an unaligned address undefined behavior?

[frederick-vs-ja]

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [expr.new], [basic.life]

Link to reflector thread (if any):

Issue description:
It seems that nothing in [expr.new] says that non-allocating placement new at an unaligned address has undefined behavior. [basic.life] p1.1 may be related, but one may think that such a new-expression just fails to create an object while being well-defined (however, the value of the new-expression seems underspecified if so).

For example, assuming alignof(double) == 8.

#include <new>

int main() {
  alignas(double) unsigned char buf[sizeof(double) + 1];
  new ((void*)(buf + 1)) double{};
}

Does the above program have undefined behavior? Or is the behavior well-defined despite that the new-expression doesn't create a double object?

It seems that the behavior should be undefined, because it generally requests unaligned access.

Suggested resolution:

[languagelawyer]

I think the standard does not even say that providing storage smaller than the object size is UB, the lifetime just does not start (not the same as «object not created»). Also, it shall speak about reachable storage size, like the wording for start_lifetime_as does.

[jensmaurer]

Maybe something like "attempting to create an object in storage smaller than the size of T or such that the alignment requirements of T are not met (dcl.align) is undefined behavior" in expr.new p24+?

Note that the "reachable" concept doesn't apply; if we run over objects in the vicinity, we'll just end their lifetimes the hard way.

[languagelawyer]

Note that the "reachable" concept doesn't apply

When it prolly should.

if we run over objects in the vicinity, we'll just end their lifetimes the hard way.

And may rebind some names/pointers to the new objects (with different values) when implementations may assume this can't happen, see e.g. https://stackoverflow.com/questions/70807452/stdlaunder-vs-placement-new-reachabibility-condition

[jensmaurer]

I don't think [basic.life] p8.5 can possibly be satisfied for non-reachable storage, so the pointer rebinding doesn't actually happen. The end result is undefined behavior when attempting to access the new object through the old pointer value.

Do you have a counterexample?

[languagelawyer]

I don't think [basic.life] p8.5 can possibly be satisfied for non-reachable storage

I think I do not see this.

Do you have a counterexample?

The linked SO question is not enough?