Consider this snippet of C++23 code:

struct MyData {
    std::int32_t value;
};

std::vector<char> read_from_net();
void send_over_net(std::vector<char>&);

...

std::vector<char> buffer = read_from_net();

std::start_lifetime_as<MyData>(buffer.data())->value = 222; // (1)

send_over_net(buffer); // (2)

Assuming all requirements to start lifetime of MyData at buffer.data() are respected:

1. Is there any UB in this code? Is starting lifetime like this and modifying field well defined?
2. Can I access original buffer as chars at (2) without UB considering that start_lifetime_as ended previous object's lifetime and started new one's?
3. Or does start_lifetime_as just start another lifetime but also preserves previous one?
4. Should I use std::launder(buffer.data())[0] to access original buffer as char array after (2)?

Consider this snippet of C++23 code:

struct MyData {
    std::int32_t value;
};

std::vector<char> read_from_net();
void send_over_net(std::vector<char>&);

...

std::vector<char> buffer = read_from_net();

std::start_lifetime_as<MyData>(buffer.data())->value = 222; // (1)

send_over_net(buffer); // (2)

Assuming all requirements to start lifetime of MyData at buffer.data() are respected:

1. Is there any UB in this code? Is starting lifetime like this and modifying field well defined?
2. Can I access original buffer as chars at (2) without UB considering that start_lifetime_as ended previous object's lifetime and started new one's?
3. Or does start_lifetime_as just start another lifetime but also preserves previous one?
4. Should I use std::launder(buffer.data())[0] to access original buffer as char array after (2)?

• c++
• language-lawyer
• undefined-behavior
• lifetime
• type-punning

• @JesperJuhl I dont see how this code is not enough, some things should stay behinds the scenes, since they don't matter in this case. It is already obvious that i want to modify existing buffer through pointer to my type not having UB. This is just modern way to do type punning, but im not sure if it is legal – Max Commented yesterday
• @JesperJuhl this example is self explanatory: at runtime you receive an array of bytes which conforms to a layout of a POD data struct, like MyData. Then you need to modify some part of it via a member. It is one of the most common things you can do in C. Your point doesn't stand here, this example is minimal and representable enough – Sergey Kolesnik Commented yesterday
• @JesperJuhl this code snippet is enough for language-lawyer tag – Sergey Kolesnik Commented yesterday
• 1 @Red.Wave there are, however, tons of materials pointing out that start_lifetime_as may be absolutely legally used in a lots of circumstances, it is just not clear if we are allowed to access original storage after such calls. Example: github/boostcon/cppnow_presentations_2024/blob/main/…, slide 79 There is UB in accessing storage as an int, yes, but in my case we have character buffer, and as we know, char* may alias anything in C++, so there is a difference – Max Commented yesterday
• 1 @Red.Wave The thing is I want to avoid any unnecessary copies at all, while you suggest the opposite. This would have been easily accomplished in C, but C++ has object semantics, so it is important to not mess with C++ abstract machine to get it right – Max Commented 23 hours ago

2 Answers 2

TL;DR It's undefined behavior.

Kudos for thinking about this.

The key points are that

1. reusing the storage to create a new object does end the lifetime of old objects¹

   https://eel.is/c++draft/basic.life#2.5

2. aliasing through char is allowed

   https://eel.is/c++draft/basic.lval#11.3

   • but you have to have a validly derived pointer, which you don't, because

3. starting lifetime of a new object of different type ends validity of all pointers into any part of that object

   https://eel.is/c++draft/basic.life#10

4. You can get a new, valid pointer through std::launder of an existing expired pointer, or through reinterpret_cast ing of a valid pointer to the new object (the pointer returned from std::start_lifetime_as).

   • With std::launder, the returned pointer is valid, but it doesn't restore validity of other expired pointers (such as the ones inside std::vector itself). Ouch.

     https://eel.is/c++draft/ptr.launder#5

¹ The one rule that might be interpreted to permit this shows up here, in the relatively-new language around

reused by an object that is not nested within

If the new object is "nested within" the old objects owned by std::array, then their lifetime continues making everything ok.

https://eel.is/c++draft/intro.object#4

But that permission applies only to unsigned char and std::byte, not plain char, so it doesn't help here.

https://eel.is/c++draft/intro.object#3

• 1.Is there any UB in this code? Is starting lifetime like this and modifying field well defined?
  Assuming if you fullfilling all the requirements the shouldnt be any undefined behaviour.
  if buffer.data() ponts to a memory region that stisfies the size and alignment requirements of MyData, the std::start_lifetime_as will succesfully start the lifetime of a MyData object at that location. In your snippet, after you start the lifetime of MyData at buffer.data(), writing to its member (i.e. setting value = 222) is a defined operation.

• 2. and 3. Yes, you can access the original buffer as char at (2) without undefined behavior.

• 4.In C++ 17 std::launder can to used to obtain pointer to an object which may have been relocated. if you want to optimize something you can use it. From my POV you dont need it because you already have an valid pointer from buffer.data().