There was some discussion of a similar issue at Stack Overflow:
https://stackoverflow.com/questions/55578429/do-we-need-to-use-stdlaunder-when-doing-pointer-arithmetic-within-a-standard-l

It appears that in C++14, the committee believed that memcpy() is
implementable in user code, then the changes to the memory model in C++17
came along, and now nobody is sure anymore. CWG 1701 referenced by T.C. is
reproduced below:

> 1701. Array vs sequence in object representation *Section: *6.7
> [basic.types] *Status: *drafting *Submitter: *Lawrence Crowl *Date:
> *2013-06-14 *Priority: *0 *Drafting: *Miller
>
> According to 6.7 [basic.types] paragraph 4,
>
> The object representation of an object of type T is the sequence of *N* unsigned
> char objects taken up by the object of type T, where *N* equals sizeof(T).
>
>
> However, it is not clear that a “sequence” can be indexed, as an array can
> and as is required for the implementation of memcpy and similar code.
>
> *Additional note, November, 2014:*
>
> An additional point of concern has been raised (see messages 25503
> <http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=25503>,
> 25505
> <http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=25505>,
> 25509
> <http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=25509>,
> 25510
> <http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=25510>,
> 25512
> <http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=25512>,
> and 25514
> <http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=25514>
> through 25518
> <http://listarchives.isocpp.org/cgi-bin/wg21/message?wg=core&msg=25518>)
> as to whether it is appropriate to refer to the constituent bytes of an
> object as being “objects” themselves, along with the interaction of this
> specification with copying or not copying parts of the object
> representation that do not participate in the value representation of the
> object (“padding” bytes).
>
And T.C. said that "the most recent discussion from a few years back do not
appear to have a clear direction."

It does appear to me that the C++17 wording, taken at face value, made a
lot of previously well-defined, perfectly sensible code UB and it surprises
me that people do not seem to be scrambling to fix this. I certainly would
like to see this fixed, but if CWG doesn't consider it a priority, I don't
know how far you'll get.

What ideas did you have regarding how to fix it?

On Sat, Jul 20, 2019 at 8:25 PM sdkrystian via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> It is - see http://eel.is/c++draft/expr.static.cast#13 and
> http://eel.is/c++draft/expr.add
>
> The cast will leave the pointer value unchanged. That means, when the
> addition is done, it is still pointing to the int object, which will result
> in a pointer past the end. Modifying it will result in UB.
>
>
>
> Sent from my Samsung Galaxy smartphone.
>
> -------- Original message --------
> From: Lyberta via Std-Discussion <std-discussion_at_[hidden]>
> Date: 7/20/19 16:34 (GMT-05:00)
> To: sdkrystian via Std-Discussion <std-discussion_at_[hidden]>
> Cc: Lyberta <lyberta_at_[hidden]>
> Subject: Re: [std-discussion] Fixing common reinterpret_cast design
> patterns
>
> sdkrystian via Std-Discussion:
> > I have been working on some wording to change the following things with
> reinterpret_cast:- allow casting to char*, unsigned char* and std::byte* to
> access the object representation of an object, and- allow casting from
> char*, unsigned char* and std::byte* to an object pointer type T, where the
> pointer being casted is a pointer to an array or first element thereof
> providing storage to an object of type TThese are very common design
> patterns that are often used, and they currently have undefined behavior. I
> would like to get a sense of if this would be something that you all would
> like to see. Please provide any feedback or suggestions 😊
> >
> >
>
> The first case is not UB:
>
>
> https://stackoverflow.com/questions/16260033/reinterpret-cast-between-char-and-stduint8-t-safe
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>

-- 
*Brian Bi*