Repository navigation
CWG2719 [expr.new] Is placement-newing an object at an unaligned address undefined behavior? #291
Description
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:
Activity
languagelawyer commentedon Apr 5, 2023
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_asdoes.jensmaurer commentedon Apr 8, 2023
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 commentedon Apr 8, 2023
When it prolly should.
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 commentedon Apr 8, 2023
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 commentedon Apr 8, 2023
I think I do not see this.
The linked SO question is not enough?
[-][expr.new] Is placement-newing an object at an unaligned address undefined behavior?[/-][+]CWG2719 [expr.new] Is placement-newing an object at an unaligned address undefined behavior?[/+]frederick-vs-ja commentedon Apr 27, 2026
It seems to me that the resolution also resolves CWG1211.
jensmaurer commentedon Apr 28, 2026
CWG2719