Subject: Re: [ub] C provenance semantics proposal
From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2019-04-04 15:17:14
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
(integrated into C++17)
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).
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.
188.8.131.52 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.
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.
SG12 list run by herb.sutter at gmail.com