<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Niall's Dxxxx "Enhanced C/C++ memory and object model" refers to P1434R0 "Discussing Pointer Provenance."<br></div><div dir="ltr">P1434R0 contains the following text.</div><div dir="ltr"><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">Equality of pointers is handled by a case analysis:<ul style="color:rgb(0,0,0);font-family:-webkit-standard"><li style="text-align:justify">[...]</li></ul><ul style="color:rgb(0,0,0);font-family:-webkit-standard"><li style="text-align:justify">if both are valid, have different provenance and compare equal, then [...]</li></ul><ul style="color:rgb(0,0,0);font-family:-webkit-standard"><li style="text-align:justify">if both are valid and have different provenance, [then] they compare not equal</li></ul></blockquote><div>The two bullet points I quoted are contradictory. The second says "two pointers with different provenance never compare equal," and the first says "if two pointers with different provenance compare equal, then..."</div><div><br></div><div>Because of inconsistencies/typos/thinkos like this, I doubt that P1434R0 is a firm footing on which to base anything at the moment. Is there a P1434R1 in the works?</div><div><br></div><div>Niall:</div><div><br></div><div><div class="gmail-page" title="Page 8" style="color:rgb(0,0,0);font-family:-webkit-standard"><div class="gmail-layoutArea"><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"><span style="font-size:11pt;font-family:SFRM1095">An object of trivially copyable, standard-layout </span><span style="font-size:11pt;font-family:SFRM1095;color:rgb(0,128,128)">, trivially attachable, or trivially detachable </span><span style="font-size:11pt;font-family:SFRM1095">type (X.X) shall occupy contiguous bytes of storage.</span></blockquote></div></div></div><div><br></div><div>The added "or" changes the meaning of the black text from "trivially copyable AND standard-layout type" to "trivially copyable OR standard-layout type." This can't possibly be intentional. I think you meant "... AND trivially detachable"; but I recommend just eliminating this green text entirely. <b><i>All</i></b> objects — even objects of non-trivially attachable types — continue to occupy contiguous bytes of storage, IIUC.</div><div><br></div><div><div class="gmail-page" title="Page 6" style="color:rgb(0,0,0);font-family:-webkit-standard"><div class="gmail-layoutArea"><div class="gmail-column"><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"><span style="font-size:11pt;font-family:SFRM1095;color:rgb(0,128,128)">A ‘reachable C++ program’ can be defined by the implementation as one of the following options [...]</span></blockquote></div></div></div></div><div><br></div><div><div class="gmail-page" title="Page 7"><div class="gmail-layoutArea"><div class="gmail-column"><blockquote class="gmail_quote" style="color:rgb(0,0,0);font-family:-webkit-standard;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:11pt;font-family:SFRM1095;color:rgb(0,128,128)">Memory pages can be concurrently accessible to more than one reachable C++ program at a time</span></blockquote><div class="gmail-column"><br></div>Avoid using the phrase "can be" in normative text. Probably what you mean is that the implementation is <i><b>required</b></i> to define "reachable C++ program" and <i><b>required</b></i> to permit concurrent access to pages; but taken literally, all this text is saying is that the implementation <i><b>can</b></i> do those things (it doesn't have to).</div></div></div></div><div><br></div><div><div class="gmail-page" title="Page 9" style="color:rgb(0,0,0);font-family:-webkit-standard"><div class="gmail-layoutArea"><div class="gmail-column"><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"><span style="font-size:11pt;font-family:SFRM1095;color:rgb(0,128,128)">An object of type </span><span style="font-size:9pt;font-family:BeraSansMono;color:rgb(0,128,128)">T </span><span style="font-size:11pt;font-family:SFRM1095;color:rgb(0,128,128)">shall have </span><span style="font-size:11pt;font-family:SFTI1095;color:rgb(0,128,128)"><i>trivial</i> </span><span style="font-size:11pt;font-family:SFRM1095;color:rgb(0,128,128)">attachment or detachment if [...]</span></blockquote></div></div></div></div><div><br></div><div>I think you meant to use the phrasing "An object of type T <i><b>is said to</b></i> have <i>trivial </i>attachment if..." Otherwise, you're putting a requirement on (somebody) that T have trivial attachment, without ever having defined what that means.</div><div>Separately, you seem to be defining "trivial attachment" as the opposite of "non-vacuous attachment," is that right? If so, that's unnecessarily confusing. The opposite of "non-vacuous" should be "vacuous," and the opposite of "trivial" should be "non-trivial."</div><div><br></div><div>It's not obvious to me what you mean by "trivially obvious changes," nor how "trivially obvious" differs from "obvious."</div><div><br></div><div>Your `auto in_place_attach<T>(span<byte>) -> span<T>` is extremely reminiscent of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0593r3.html#direct-object-creation">P0593R3</a>'s not-yet-proposed-but-likely-to-get-proposed `auto bless<T>(void *p) -> T*`. It would be nice to compare and contrast what's going on there, or even try to harmonize the two papers.</div><div><br></div><div><div class="gmail-page" title="Page 15" style="color:rgb(0,0,0);font-family:-webkit-standard"><div class="gmail-layoutArea"><div class="gmail-column"><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"><span style="font-size:11pt;font-family:SFRM1095">As trivially attachable and detachable types have default attachment and detachment implementations in this proposal, that would mean that all types without pointers and references within them can now be relocated. This substantially expands the number of types whose move constructor and move assignment could be defaulted, and whose representation can be transported in CPU registers instead of on the stack.</span></blockquote></div></div></div></div><div><br></div><div>I think I agree with the gist of this section, but I don't understand what you mean by "This substantially expands the number of types whose <i><b>move constructor and move assignment could be defaulted</b></i>." Relocation-by-detachment-and-attachment has nothing to do with move-construction, let alone move-assignment.</div><div><br></div><div> struct file_descriptor {</div><div> int fd = -1;</div><div> file_descriptor(file_descriptor&& rhs) noexcept : fd(rhs.fd) { rhs.fd = -1; }</div><div> ~file_descriptor() { if (fd != -1) close(fd); }</div><div> };</div><div><br></div><div>This `struct file_descriptor` should be "trivially relocatable" by anyone's definition. But it obviously can't have a defaulted move-constructor, because it does not have a defaulted destructor. RAII types must still follow the Rule of Three / Rule of Five. And higher-level types can follow the Rule of Zero. Higher-level types following the Rule of Zero will already default all their special members and thus do not gain anything in that department from being "trivially attachable and/or detachable."</div><div><br></div><div>my $.02,</div><div>–Arthur</div><div dir="ltr"><br></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 26, 2019 at 5:24 PM Niall Douglas <<a href="mailto:s_sourceforge@nedprod.com">s_sourceforge@nedprod.com</a>> 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">Bounced due to low attachment size limit. I uploaded a copy of the draft<br>
paper to:<br>
<br>
<a href="https://dedi5.nedprod.com/static/files/other/Dxxxx%20draft%202%20-%20Enhanced%20C%2B%2B%20memory%20and%20object%20model.pdf" rel="noreferrer" target="_blank">https://dedi5.nedprod.com/static/files/other/Dxxxx%20draft%202%20-%20Enhanced%20C%2B%2B%20memory%20and%20object%20model.pdf</a><br>
<br>
Niall<br>
<br>
-------- Forwarded Message --------<br>
Subject: Draft 2 of Enhanced C/C++ memory and object model<br>
Date: Mon, 25 Mar 2019 13:16:10 +0000<br>
From: Niall Douglas <<a href="mailto:s_sourceforge@nedprod.com" target="_blank">s_sourceforge@nedprod.com</a>><br>
To: <a href="mailto:ub@isocpp.open-std.org" target="_blank">ub@isocpp.open-std.org</a><br>
CC: Jens Gustedt <<a href="mailto:jens.gustedt@inria.fr" target="_blank">jens.gustedt@inria.fr</a>>, Uecker, Martin<br>
<<a href="mailto:Martin.Uecker@med.uni-goettingen.de" target="_blank">Martin.Uecker@med.uni-goettingen.de</a>>, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
<br>
Dear SG12,<br>
<br>
CC: Relevant members of WG14, and Hal<br>
<br>
Please find attached draft 2 of my upcoming SG12 and WG14 targeted paper<br>
proposing an enhanced memory and object model for C++ and C based around<br>
implementing a subset of P1434 "Discussing pointer provenance" to make<br>
much more rigorous the modification of memory, and adding two new core<br>
operations to objects:<br>
<br>
1. Detachment, the reinterpretation of a live object into an array of<br>
bytes representing that object.<br>
<br>
2. Attachment, the reinterpretation of a previously detached object<br>
representation into a live object.<br>
<br>
It is believed that these changes are sufficient to implement memory<br>
shared between concurrent processes, memory mapped in from another<br>
device by DMA, process bootstrap from a database of shared binary<br>
Modules, and the elemental operations for implementing zero-copy<br>
serialisation and deserialisation.<br>
<br>
One also gains object relocation in memory, and substantially enhanced<br>
default move implementations which can use CPU registers for object<br>
transport.<br>
<br>
<br>
I appreciate that this proposal is huge, the standardese in the paper<br>
meagre and incomplete, and chances of success are very low. Still, I<br>
hope to discuss it at Cologne and subsequent SG12 meetings, if Gaby<br>
wishes to give time to it. I'll also be taking it to the May WG14<br>
meeting, and see how much the C folk hate it.<br>
<br>
Feedback is welcome.<br>
<br>
Niall<br>
</blockquote></div></div></div></div></div></div></div></div></div></div></div></div>