Subject: Re: Fixing common reinterpret_cast design patterns
From: Brian Bi (bbi5291_at_[hidden])
Date: 2019-07-20 20:06:17
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
> 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
> and 25514
> through 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 <
> It is - see http://eel.is/c++draft/expr.static.cast#13 and
> 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
> 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:
> Std-Discussion mailing list
-- *Brian Bi*
STD-DISCUSSION list run by herb.sutter at gmail.com
Older Archives on Google Groups