On 04/04/2019, Jens Maurer <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

Thanks for these pointers.

> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0137r1.html
> (integrated into C++17)

This is mostly addressing different issues to the provenance questions
that the three notes we circulated address. It implicitly assumes
that one can distinguish between a pointer one-past one object from a
pointer to the start of an adjacent object, e.g. in

  Change in 3.9.2 (basic.compound) paragraph 3:

  [...] A pointer past the end of an object is not considered to
  point to an unrelated object of the object's type that might be
  located at that address. [...]

while the provenance proposal defines (among other things) exactly how
and when one can make such distinctions, even in the presence of
pointer/integer casts, accesses to pointer representation bytes,
pointer I/O, and suchlike. I don't so far see any incompatibility
between the proposals.


> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0593r3.html

This too is concerned with different issues: implicit object creation
and effective types, not provenance.

The WG14 memory object model study group is now turning its attention
to the C notion of effective types, and the treatment of subobjects;
that will relate more closely to the notes you point to.


> It would be nice if C and C++ moved into the same direction here.

Absolutely.

>> 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.

This is only a corner of the provenance proposal, but also important.

C distinguishes equality (==, !=) and relational (<, <=, >, >=) comparison.

Inter-object equality comparison has to be supported, though there's some
debate about what the semantics should be in the one-past case -
whether the result should be allowed to be provenance-sensitive or not.

Inter-object relational comparison is not allowed in ISO C. Perhaps that's
also debatable, as real code seems to rely on it, but it's not the main
subject of the provenance proposal - probably best not to go into it right now.

thanks,
Peter


> Jens
>