On Thu, Apr 4, 2019 at 1:22 PM 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
>
> 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.
>

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).
> > 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
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>