21

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{};
Oliv
  • 17,610
  • 1
  • 29
  • 72

1 Answers1

13

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.

T.C.
  • 133,968
  • 17
  • 288
  • 421
  • And for the second example, does it make sense? – Oliv Jan 02 '18 at 20:47
  • 1
    Same answer. The remaining `2*sizeof(int)` bytes of the array is not reachable through `pi`. – T.C. Jan 02 '18 at 20:49
  • TIL that cxxdraft-htmlgen creates links to individual sentences as well. Neat – StoryTeller - Unslander Monica Jan 02 '18 at 22:13
  • @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. – supercat Jan 03 '18 at 07:13
  • @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. – supercat Jan 03 '18 at 07:19
  • 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? – xskxzr May 03 '18 at 15:40
  • 1
    @xskxzr No. See the linked definition of "reachable" and the *Requires:* clause. – T.C. May 04 '18 at 09:38