"associated contractual precondition"

Contracts are defined for functions, not for built-in operations.
If you want to extend the concept, it might be better to
avoid the word "contract" and "precondition" and just
state the conditions and the effects when violated.


4.6.1
"non-void, non-null, non-function pointer object"

This mixes value with type and has a lot of "non".
Also, is this intended to cover only pointer objects
(i.e. pointers that are materialized somewhere in memory)
or also pointer values (which might live in a register)?
I think this wants to talk about both.

Suggestion: "non-null pointer to object"

Where did "safely-derived pointer value" go? The section
was replaced entirely, it seems.


"The following operations involving two non-void, non-null pointers shall fail to compile with a
diagnostic:
Comparisons, including equality and inequality, of two pointers without common provenance
(user should convert to void* beforehand)."

It seems "provenance" of a pointer is a runtime property, so how can
that cause a compile-time diagnostic?


Jens



On 26/03/2019 22.23, Niall Douglas wrote:
> Bounced due to low attachment size limit. I uploaded a copy of the draft
> paper to:
>
> https://dedi5.nedprod.com/static/files/other/Dxxxx%20draft%202%20-%20Enhanced%20C%2B%2B%20memory%20and%20object%20model.pdf
>
> Niall
>
> -------- Forwarded Message --------
> Subject: Draft 2 of Enhanced C/C++ memory and object model
> Date: Mon, 25 Mar 2019 13:16:10 +0000
> From: Niall Douglas <s_sourceforge_at_[hidden]>
> To: ub_at_[hidden]
> CC: Jens Gustedt <jens.gustedt_at_[hidden]>, Uecker, Martin
> <Martin.Uecker_at_[hidden]>, Hal Finkel <hfinkel_at_[hidden]>
>
> Dear SG12,
>
> CC: Relevant members of WG14, and Hal
>
> Please find attached draft 2 of my upcoming SG12 and WG14 targeted paper
> proposing an enhanced memory and object model for C++ and C based around
> implementing a subset of P1434 "Discussing pointer provenance" to make
> much more rigorous the modification of memory, and adding two new core
> operations to objects:
>
> 1. Detachment, the reinterpretation of a live object into an array of
> bytes representing that object.
>
> 2. Attachment, the reinterpretation of a previously detached object
> representation into a live object.
>
> It is believed that these changes are sufficient to implement memory
> shared between concurrent processes, memory mapped in from another
> device by DMA, process bootstrap from a database of shared binary
> Modules, and the elemental operations for implementing zero-copy
> serialisation and deserialisation.
>
> One also gains object relocation in memory, and substantially enhanced
> default move implementations which can use CPU registers for object
> transport.
>
>
> I appreciate that this proposal is huge, the standardese in the paper
> meagre and incomplete, and chances of success are very low. Still, I
> hope to discuss it at Cologne and subsequent SG12 meetings, if Gaby
> wishes to give time to it. I'll also be taking it to the May WG14
> meeting, and see how much the C folk hate it.
>
> Feedback is welcome.
>
> Niall
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>