<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014–03–20, at 5:25 AM, Jens Maurer <<a href="mailto:Jens.Maurer@gmx.net">Jens.Maurer@gmx.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 03/18/2014 06:06 AM, David Krauss wrote:<br><blockquote type="cite">uint32_t datum = * (net_word< uint32_t > *) buf_ptr;<br></blockquote><br>What's "buf_ptr”? </blockquote><div><br></div><div>A blob of data with no dynamic type. It’s supposed to be idiomatic, cast-happy C using a memory overlay struct.</div><br><blockquote type="cite">Anyway, you seem to be aliasing a net_word<br>with a uint32_t, which seems to be undefined behavior according<br>to 3.10p10.<br></blockquote><div><br></div>“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.”</div><div><br></div><div>The only value being accessed after the alias is through an lvalue of char type.</div><div><br></div><div>The address of the <font face="Courier">net_word</font> 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 <font face="Courier">reinterpret_cast< char * >( this )</font> and there would be no access to the class object whatsoever.</div><div><br></div><div>Merely forming a pointer is not aliasing. You can cast pointers to whatever and back per [expr.reinterpret.cast] 5.2.10/7.</div><div><br><blockquote type="cite"><blockquote type="cite">Is it any safer to jump through a little hoop with placement new?<br><br>uint32_t datum = * new( buf_ptr ) net_word< uint32_t >;<br></blockquote><br>This destroys the previous contents of *buf_ptr, from a<br>specification point-of-view.<br></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><blockquote type="cite">Would any part of this mayhem be vulnerable to future semantic restrictions?<br></blockquote><br>Which part of the future do you wish me to predict?<br></blockquote><div><br></div><div>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.</div></div><br></body></html>