On 13/04/2019 02.03, Richard Smith wrote:
> On Thu, Apr 4, 2019 at 1:22 PM Jens Maurer <Jens.Maurer_at_[hidden] <mailto:Jens.Maurer_at_[hidden]>> wrote:
>
> On 02/04/2019 10.16, Peter Sewell wrote:
> > continuing the discussion from last year at EuroLLVM, the GNU Tools Cauldron,
> > and elsewhere, we (the WG14 C memory object model study group) now
> > have a detailed proposal for pointer provenance semantics, refining
> > the "provenance not via integers (PNVI)" model presented there.
> > This will be discussed at the ISO WG14 C standards committee at the
> > end of April, and comments from the community before then would
> > be very welcome. The proposal reconciles the needs of existing code
> > and the behaviour of existing compilers as well as we can, but it doesn't
> > exactly match any of the latter, so we'd especially like to know whether
> > it would be feasible to implement - our hope is that it would only require
> > minor changes.
>
> There is ongoing work regarding details of the C++ memory model; see
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0137r1.html
> (integrated into C++17)
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0593r3.html
>
> It would be nice if C and C++ moved into the same direction here.
>
>

> C++ has had a pointer provenance model since p0137r1 (and has had wording that assumed pointer provenance, despite the lack of a specified model, for a long time prior to that in [basic.life]). Under that model, C++ pointers notionally track which object they point to, and an object is an abstraction within the abstract machine with much stronger semantics than C's simple "region of storage". We lack a provenance model for pointers cast to integers; we only say that round-tripping a pointer through an integer produces the same pointer value -- that is, pointing to the same abstract object, not merely representing the same address -- but say nothing about (for instance) what happens if multiple pointer values representing the same address are cast to integers and back, or what it would mean to compute an integer value (that happens to be equal to the result of some prior pointer-to-integer cast) and cast that to a pointer. The right model may well be to perform an implicit
> launder on a cast from integer to pointer, but this is an area where aligning with the C provenance model would likely be a very good idea.

For integer <-> pointer casts (in particular if the integer came from arithmetic
or from disk), C++ still seems to be lacking rules. I think it would be good
if C++ would consider aligning with future-C (or vice versa) for this corner case.
Given that in C++, provenance == object identity, I'm not sure C++ will be able
to re-use any provenance-infused words from future-C here.

Jens