C++ Logo


Advanced search

Re: Fixing common reinterpret_cast design patterns

From: Brian Bi <bbi5291_at_[hidden]>
Date: Sat, 20 Jul 2019 21:06:17 -0400
There was some discussion of a similar issue at Stack Overflow:

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*

Received on 2019-07-20 20:08:27