Using std::launder to "validate" non "pointer to object" pointer value since C++17

Question

According to this answer, since C++17, even if a pointer has the right address and the right type dereferencing it can cause undefined behaviour.

 alignas(int) unsigned char buffer[2*sizeof(int)];
 auto p1=new(buffer) int{};
 auto p2=new(p1+1) int{};
 *(p1+1)=10; // UB since c++17

The reason is that the pointer value of p1+1 is a pointer past-the-end of an object. Can this example be brought back to defined behavior using std::launder:

 *std::launder(p1+1)=10; // still UB?  

Secondly, would it also be useful in this following case?

alignas(int) unsigned char buffer[3*sizeof(int)];
auto pi = new (buffer) int{};
auto pc = reinterpret_cast<unsigned char*>(pi);//not a "pointer to" an element of buffer 
                                               //since buffer[0] and *pc 
                                               //are not pointer interconvertible
//pc+2*sizeof(int) would be UB
auto pc_valid = std::launder(pc) //pc_valid is a pointer to an element of buffer
auto pc_valid2 = pc_valid+2*sizeof(int); //not UB thanks to std::launder
auto pi2 = new (pc_valid2) int{};

Kazimir

Answer 1

No. The bytes constituting the int object p2 points to are not reachable through p1+1.

---

The "reachable" rule basically means that launder doesn't allow you to access storage you can't legally access via the original pointer. Since an opaque function may launder pointers as much as it wants, permitting this kind of shenanigans would substantially inhibit escape analysis.

Lal

And for the second example, does it make sense? – Kazimir

Same answer. The remaining 2*sizeof(int) bytes of the array is not reachable through pi. – Lal

TIL that cxxdraft-htmlgen creates links to individual sentences as well. Neat – Zulmazulu

@T.C.: I can certainly see the need to distinguish pointers which will never be used to derive outside objects from those that might, but a language which doesn't have any pointer types that can retain the ability to derive the addresses of outside objects is fundamentally weaker than one which does. – Shebashebang

@T.C.: Further, what's often needed is not the ability to launder a pointer and have it be usable indefinitely, but rather the ability to create a pointer to an object which can access other objects but, for its lifetime, would be subject to limitations akin to C's restrict. Essentially, the creation and destruction of such a pointer would act as sequencing barriers, but use of them would not. Code which creates such pointers within a tight loop might perform badly, but being able to put barriers outside a loop may allow more efficient code than would otherwise be possible. – Shebashebang

But in the second example, he only uses std::launder to get a pointer (pc_valid) to the first element of the buffer, isn't it valid? – Pickle

@Pickle No. See the linked definition of "reachable" and the Requires: clause. – Lal