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.

> N2362 Moving to a provenance-aware memory model for C: proposal for C2x
> by the memory object model study group. Jens Gustedt, Peter Sewell,
> Kayvan Memarian, Victor B. F. Gomes, Martin Uecker.
> This introduces the proposal and gives the proposed change to the standard
> text, presented as change-highlighted pages of the standard
> (though one might want to read the N2363 examples before going into that).
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2362.pdf

6.2.4 bullet in p8 "typically identifying"
The word "typically" seems misplaced in normative text.
This seems to want to define "provenance" (it's in italics),
so we need a real definition here. Oh, but 3.17 already
defines "pointer provenance", so maybe we don't need a
separate definition here.

6.2.6.1 defines "storage instance is exposed", yet footnote 58 then
refers to "exposed provenance". That feels like a mismatch.

> N2363 C provenance semantics: examples.
> Peter Sewell, Kayvan Memarian, Victor B. F. Gomes, Jens Gustedt, Martin Uecker.
> This explains the proposal and its design choices with discussion of a
> series of examples.
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2363.pdf

It seems to me that most of the introductory examples have clear
answers in current C++. In particular:

— If one pointer represents the address of a complete object, and another pointer represents the address
  one past the last element of a different complete object, the result of the comparison is unspecified.

The proposal in N2362 seems to make such a comparison yield "true".

I actually like our current rule: never ever compare / subtract pointers
to different complete objects. If you must compare, use std::less.

Jens