LWG 4064: Clarify that std::launder is not needed when using the result of std::memcpy

[jwakely]

Could CWG please take a look at this proposed resolution and confirm that they're happy with it:
https://cplusplus.github.io/LWG/issue4064

[jensmaurer]

CWG 2024-06-25 in St. Louis: The proposed resolution is not correct, because there are situations in which memcpy works (because it is operating on a trivially copyable type), yet the type in question is not an implicit lifetime type. In that case, there is no "suitable created object". (An example of such a type is one with a trivial destructor and a trivial copy assignment operator where all other special member functions are deleted.)

Suggested amendments to the proposed resolution, including a drive-by fix to make everything singular:

The functions memcpy and memmove are signal-safe (17.13.5 [support.signal]). Both Each of these functions implicitly create creates objects (6.7.2 [intro.object]) in the destination region of storage immediately prior to copying the sequence of characters to the destination. Each of these functions returns a pointer to a suitable created object, if any, otherwise the value of the first parameter.

CWG asks that the LWG issue is sent to CWG again for approval, after any amendments LWG might have done.

[jwakely]

LWG accepted the suggested wording from CWG and moved it to Ready status. If CWG want to look at it again, please feel free to do so. We can reopen it if you want to change it, otherwise it will get polled in Wrocław.

[jensmaurer]

CWG 2024-11-18 in Wroclaw: Approved.