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. It’s 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; it’s 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?
There’s 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.