Subject: Re: [ub] data overlays: reinterpret_cast vs placement new
From: David Krauss (david_work_at_[hidden])
Date: 2014-03-20 06:05:12
On 20140320, at 5:25 AM, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> On 03/18/2014 06:06 AM, David Krauss wrote:
>> uint32_t datum = * (net_word< uint32_t > *) buf_ptr;
> What's "buf_ptr?
A blob of data with no dynamic type. Its supposed to be idiomatic, cast-happy C using a memory overlay struct.
> Anyway, you seem to be aliasing a net_word
> with a uint32_t, which seems to be undefined behavior according
> to 3.10p10.
If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
a char or unsigned char type.
The only value being accessed after the alias is through an lvalue of char type.
The address of the net_word is the same as the address of its first member, so if member access expressions run afoul of 3.10/10 (certainly on-topic for this question; its not clear to me that they do), the functions could reinterpret_cast< char * >( this ) and there would be no access to the class object whatsoever.
Merely forming a pointer is not aliasing. You can cast pointers to whatever and back per [expr.reinterpret.cast] 5.2.10/7.
>> Is it any safer to jump through a little hoop with placement new?
>> uint32_t datum = * new( buf_ptr ) net_word< uint32_t >;
> This destroys the previous contents of *buf_ptr, from a
> specification point-of-view.
It runs the constructor of a trivially-constructible class, which does nothing and has no particular significance. The object lifetime already began when storage with the proper alignment and size for type T is obtained, which occurred when the data blob was allocated.
>> Would any part of this mayhem be vulnerable to future semantic restrictions?
> Which part of the future do you wish me to predict?
Theres been quite a bit of discussion on this group about adjusting the aliasing and lifetime rules. The last I recall, new-expressions were being considered to become more significant with respect to object lifetime and dynamic type.
SG12 list run by herb.sutter at gmail.com