<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Calisto MT";
        panose-1:2 4 6 3 5 5 5 3 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calisto MT","serif";
        color:#7030A0;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Calisto MT","serif";color:#7030A0">I really don’t understand that you mean by ‘lifetime is a meaningless concept for POD’. The C standards has had several aliasing bugs related to lifetime. I also do not understand
“lifetime is required to exist in a retroactive sense around every subobject access.” I think we have a lot of confusion already.<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-family:"Calisto MT","serif";color:#7030A0"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> ub-bounces@open-std.org [mailto:ub-bounces@open-std.org]
<b>On Behalf Of </b>David Krauss<br>
<b>Sent:</b> Friday, January 17, 2014 7:16 AM<br>
<b>To:</b> WG21 UB study group<br>
<b>Subject:</b> Re: [ub] type punning through congruent base class?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Jan 17, 2014, at 9:53 PM, Gabriel Dos Reis <<a href="mailto:gdr@microsoft.com">gdr@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calisto MT","serif";color:#7030A0">As for an object type with “trivial initialization”, I suspect that the general confusion comes from the fact for some reasons the standards text assumed that it could just “optimize”
that case without much confusion. But evidence appear to suggest otherwise. Complexity has grown, with increased likelihood of inconsistency. What is the meaning of T{ } when T is a POD struct? Do you think there is no lifetime there? </span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My impression (for what it’s worth) is that a lifetime is required to exist in a retroactive sense around every subobject access. But the lifetime of a POD object does nothing but grant the possibility of accessing a subobject, which in
turn has no special properties or invariants by virtue of the complete object.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So it’s not to say there’s no lifetime there, but POD lifetime is a meaningless concept because you can always just pull one out of thin air. (T{} is value-initialized, and assigning those zeroes does imply subobject accesses to be sure.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What evidence otherwise? It sounds like Richard is trying to push the envelope, but one would have to review existing verification/test tools to see if anyone has really tried to do anything with POD lifetimes. In a very real sense, POD
objects are handed to any C++ program by the OS libraries in a fashion opaque to (outside the scope of) most verification tools. Programs need original input data to come out of thin air, and POD provides a way to structure such data while preserving its bytestream-like
purity.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>