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.
Well, it depends on what that direction is. C++ deliberately has a /much/ stronger story for type-safety, lifetime, and pointer semantics than C, and already disallows a lot of the weird things that the C specification permits. C++ should not move in the direction of C here without very careful consideration; our current approach of moving to more-precisely-defined, restrictive rules, and then carefully carving out allowances for type unsafety where we really need it, seems to be working well. We shouldn't give that up for C compatibility. And conversely, I wouldn't expect C to embrace the type safety of C++ if it would invalidate existing programs that do type punning via the "visible union" rule that some believe to be part of the C rules.
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.
> 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.
184.108.40.206 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.
ub mailing list