Repository navigation
Example in [allocator.requirements.general] incorrectly uses launder? #4553
Description
Activity
The usage is indeed incorrect. The valid cast is
launder(reinterpret_cast<T(*)[n]>(new (p) byte[n * sizeof(T)]))(May benis not necessary) I believe. The problem is that value of the array (as a pointer) is valid pointer for purposes of arithmetic and casting to it and laundering it should be allowed as long as I do not de-reference it, (without constructing an object first).These operations select one of the implicitly-created objects whose address is the address of the start of the region of storage, and produce a pointer value that points to that object, if that value would result in the program having defined behavior.
Incidentally, the standard never specifies which implicitly created objects whose addresses are the address of the start of the region of storage.
That's intentional. The right one is selected, by magic, if that would make the program correct.
None of this is editorial.
That's intentional. The right one is selected, by magic, if that would make the program correct.
So, we cannot plainly determine whether a program is well-formed. For instance
struct X{ int x; }; auto ptr = (X*)malloc(sizeof(X)); ptr->x = 0;// is well-formed?
No one can say the return value of
malloccan be the address of objectX. AlthoughXis implicitly-lifetime type, however, we don't know whether that object's address is the address of the start of the region of storage. I.E., only the implementor of the functionmallocknows that.No, that's not what the wording means. There is no "implementor of the function
malloc," because it's part of the implementation and so behaves as the standard says (not as some developer says). The standard says that if beginning the lifetime of an object of typeXat that location would make the program have defined behaviour, then that's what happens. So the answer to the "is well-formed?" question is yes. By definition. If creating anXthere makes it well-formed, then that's what happens, and so it's well-formed.«well-formed» should not be confused with «well-defined»
Reacted by XMH and A. JiangYes, and
ptr->x = 0is always well-formed whenptrhas typeX*. It's also well-defined becausemallocimplicitly creates objects of the type needed to make it have defined behaviour.@jwakely However, the standard/implementation never says that the object of type
Xwould be located at the start address of that region. This is the confusion here. Actually, [intro.object] p11 imposes two requirements:- these objects shall have an implicitly-lifetime type.
- these objects' addresses shall be the address of the start of the region of storage.
we can say the object of type
Xsatisfies the first bullet since the standard defines the "implicitly-lifetime type", hencemallocimplicitly creates the object with typeX. However, the standard never says these objects' addresses are what(i.e., whether their addresses satisfy the second bullet). Based on this logic, we cannot determine whetherptr->x = 0;is well-defined or not.Cite the quotes of the definition of
mallocin CDescription:
- The malloc function allocates space for an object whose size is specified by size and
whose value is indeterminate.
Returns
- The malloc function returns either a null pointer or a pointer to the allocated space.
struct T{ int i; char c; }; auto tptr = (T*)malloc(sizeof(T)); tptr-> a = 0; auto iptr = (int*)malloc(sizeof(T)); *iptr = 0;
The standard only specifies that an object of type
Tand the member subobjectT::iis pointer-interconvertible, hence they have the same address. However, neither in C++ nor C standard, they ever specify, through any provision, that the addresses of a typeTobject and its subobjectT::iare identical to the address of the start of the region of the storage that is allocated by themallocfunction. when we say the above example is well-defined is just based on the premise that these objects whose addresses are the address of the start of the allocated space. However, this premise has no formal definition to prove in the current standard.- The malloc function allocates space for an object whose size is specified by size and
P2590R0 addressed this issue by replace the use with
start_lifetime_as_array<T>(p, n), but this change was removed in later revisions.Yes, because that's a situation where we're not intending to re-use the existing bytes for the to-be object representation. As-is, the optimizer can apply dead-store elimination for any store to the affected region.
start_lifetime_as_array<T>(new (p) byte[n * sizeof(T)], n)seemingly works as intended. Although there's an open issue CWG1997 indicating that it may be unclear whether the new-expression renders the contents in the storage indeterminate.That core issue far predates
std::start_lifetime_as. I think the goal of CWG1997 is (and continues to be) to clarify that placement-new without initialization also yields an object with indeterminate value.Reacted by A. JiangThe goal of CWG1997, in the first place, should be to clarify that the lifetime of objects created by new-expression using non-allocating
operator newstarts, because «obtaining storage» is a precondition to lifetime start, and somehow there is doubt that non-allocatingoperator newobtains storage 🤡Although std::launder should not be required at all and everything should correct itself.
- According to the standard, "operations" that begin the lifetime of std::byte array should implicitly create an object! http://eel.is/c++draft/basic.memobj#intro.object-13
- And in the case of non-implicit type, it would be just a pointer * before * the start of a lifetime!
Example for (1). If the object is created implicitly, then placement new shall return a pointer to it. Therefore this is a perfectly valid code point to the first element of the array.
struct A { int p; }; std::byte s[100 * sizeof(A)]; reinterpret_cast<A*>(new (s) std::byte[100 * sizeof(A)])[4].p = 100; //OK?If the object is created implicitly, then placement new shall return a pointer to it.
@MX20
new ... T[N], for N > 0, always returns the pointer to the first element of the «array of NT» http://eel.is/c++draft/expr.new#10.sentence-1Right , but what does it change? For non implicitly created types it may be the pointer to the first element before its lifetime started which can be used in limited ways - just enough to create an object in it using another placement new
Right , but what does it change?
That
new (s) std::byte[…]always returns a pointer to the first element of the array of somestd::bytes, and implicitly created objects do not affect this.I see , fair enough
I think there's an interesting decision for CWG to make here. I agree with the issue description:
When reusing storage denoted by some pointer value
p,launder(reinterpret_cast<T*>(new (p) byte[n * sizeof(T)]))can be used to implicitly create a suitable array object and obtain a pointer to it.If
Tis not an implicit-lifetime type, then, even if an object of typeT[m ≤ n]is created, the lifetimes of the array elements are not started, which meanslaunder's preconditions are violated:Preconditions:
prepresents the addressAof a byte in memory. An objectXthat is within its lifetime and whose type is similar toTis located at the addressA.(If
Tis an implicit-lifetime type, or even for all typesT,laundermay not even be required, see below)I think we can resolve the disagreement between the claim about a valid use of
launderand the precondition oflaunderin (at least) three ways. We could say that:- The claim is wrong, and we should update the text to suggest a different approach, such as [allocator.requirements.general] Fix the misuse of
launder#6452 if that works. - The precondition of
launderis wrong, and it should alternatively suffice for there to exist an array object of typeT[n]within its lifetime such thatprepresents the address of an element of the array, which need not be within its lifetime. - (Really a special case of (1).) We want a separate
launder_arrayfunction for this case.
Option 2 is probably the simplest if it works.
Reacted by A. Jiang- The claim is wrong, and we should update the text to suggest a different approach, such as [allocator.requirements.general] Fix the misuse of
- The precondition of
launderis wrong, and it should alternatively suffice for there to exist an array object of typeT[n]within its lifetime such thatprepresents the address of an element of the array, which need not be within its lifetime.
Option 2 is probably the simplest if it works.
int arr[1]; for (int i = 0; i < INT_MAX; i++) ::new (&arr[0]) int {}; std::launder(&arr[0]); // which of INT_MAX+1 objects std::launder returns pointer to?
- The precondition of
int arr[1]; for (int i = 0; i < INT_MAX; i++) ::new (&arr[0]) int {}; std::launder(&arr[0]); // which of INT_MAX+1 objects std::launder returns pointer to?
The rule for transparently replacing makes all of these pointer values equivalent, IIUC.
From https://stackoverflow.com/q/66755218
[tab:cpp17.allocator] has the following example added by p0593r6:
If
Tis not an implicit-lifetime type, then, even if an object of typeT[m ≤ n]is created, the lifetimes of the array elements are not started, which meanslaunder's preconditions are violated: