<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 9, 2018 at 5:50 PM, David Vandevoorde <span dir="ltr">&lt;<a href="mailto:daveed@edg.com" target="_blank">daveed@edg.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Feb 9, 2018, at 5:46 PM, Richard Smith &lt;<a href="mailto:richardsmith@googlers.com" target="_blank">richardsmith@googlers.com</a>&gt; wrote:</div><br class="m_-2665962928092924598Apple-interchange-newline"><div><div dir="ltr" style="font-family:BookmanOldStyle;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><span class=""><div dir="ltr">On Fri, 9 Feb 2018 at 14:25, David Vandevoorde &lt;<a href="mailto:daveed@edg.com" target="_blank">daveed@edg.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div>On Feb 9, 2018, at 4:57 PM, Richard Smith &lt;<a href="mailto:richardsmith@googlers.com" target="_blank">richardsmith@googlers.com</a>&gt; wrote:</div><br class="m_-2665962928092924598m_-6140506200552420465Apple-interchange-newline"><div><div dir="ltr" style="font-family:BookmanOldStyle;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div dir="ltr">On Fri, 9 Feb 2018 at 13:08, Myria &lt;<a href="mailto:myriachan@gmail.com" target="_blank">myriachan@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Is it worth mentioning that an implementation may have other<br>mechanisms that create storage in the manner of malloc?  For example,<br>it&#39;d make sense for VirtualAlloc or mmap to create implicit objects<br>just like the standard malloc functions.<br></blockquote><div><br></div><div>Sounds like a good change to me.</div><div> </div></div></div></div></blockquote><br></div><div>It would be nice if we could indicate that in a portable way.  The default is wrong for attributes, unfortunately, but otherwise something like:</div><div><br></div><div><span class="m_-2665962928092924598m_-6140506200552420465Apple-tab-span" style="white-space:pre-wrap">        </span>[[blessed_storage]] void* my_memory_map(…);</div><div><br></div><div>would have been useful.</div></div></blockquote><div><br></div></span><div>Yes, it&#39;s annoying that attributes don&#39;t work out here. I think we won&#39;t need any annotations at all in the actual source code for most such functions in practice, because these functions result in syscalls that are opaque to the optimizer anyway (for all it knows, the kernel might have created objects in the storage...). But there are likely exceptions that have a C++ implementation that might get combined with the program source code via link-time optimization, and we do need to avoid bad things happening in that case.</div></div></div></div></blockquote><div><br></div><div>Although in those cases the C++ implementation can have a barrier “bless” call on the inside, right?</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:BookmanOldStyle;font-size:18px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>Incidentally, I’m not too fond of the name “bless”.  Maybe “implicit_lifetime”?</div></div></blockquote><div><br></div></span><div>Maybe I should just call it `bikeshed` until this gets to LEWG :)</div></div></div></div></blockquote><br></div><div>Hopefully nobody will bless bikeshed :-P</div></div></blockquote><div><br><br></div><div>Didn&#39;t LEWG already call it byte_cast?  I mean bit_cast?<br></div><div>How is this different?<br></div><div>Or does bit_cast need to call bless/bikeshed?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div><span class="m_-2665962928092924598Apple-tab-span" style="white-space:pre-wrap">        </span>Daveed</div><div><br></div><div><br></div><br></div><br>______________________________<wbr>_________________<br>
ub mailing list<br>
<a href="mailto:ub@isocpp.open-std.org">ub@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/ub" rel="noreferrer" target="_blank">http://www.open-std.org/<wbr>mailman/listinfo/ub</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>