Re: [PATCH] doc: clarify the situation with pointer arithmetic

[Martin Sebor <msebor at gmail dot com>]

On 1/22/20 8:32 AM, Richard Biener wrote:
> On Tue, 21 Jan 2020, Alexander Monakov wrote:
>
> > On Tue, 21 Jan 2020, Richard Biener wrote:
> >
> > > Fourth.  That PNVI (I assume it's the whole pointer-provenance stuff)
> > > wants to get the "best" of both which can never be done since a compiler
> > > needs to have a way to be conservative - in this area it's conflicting
> > > conservative treatment which is impossible.
> >
> > This paragraph is unclear, I don't immediately see what the conflicting goals
> > are. The rest is clear enough given the previous discussions I saw.
> >
> > Did you mean the restriction that you cannot do arithmetic involving two
> > integers based on pointers, get a value corresponding to one of them,
> > cast it back and get a pointer suitable for accessing either of two
> > originally pointed-to objects? I don't see that as a conflict because
> > it places a restriction on users, not the compiler.
>
> As far as I remember the discussions PNVI requires to track
> provenance for correctness, you may not miss or attach wrong provenance
> to a pointer and there's only "single" provenance, not "many"
> (aka, may point to A and B).  I don't see how you can ever implement that.

The PVNI variant preferred by the object model group is referred
to as "PNVI-ae-udi" which stands for "PNVI exposed-address user-
disambiguation."  (The PNVI part stands for "Provenance Not Via
Integers.)  This base PVNI model basically prohibits provenance
tracking via integers, making it possible for programs to derive
pointers to unrelated objects via casts between pointers and
integers (and modifying the integer in between the casts).  This
is considered a new restriction on implementations because
the standard doesn't permit it (as you said upthread, all it
specifies is that a pointer is equal to one obtained by casting
the original to a intptr_t and back).

The -ae-udi variant limits this restriction on implementations
to escaped pointers and provides a means for users/programs to
disambiguate between pointers to adjacent objects (i.e., a past
the end pointer and one to the beginning of the object stored
there).  The latest proposal is in N2362, with an overview in
N2378).  At the last WG14 meeting there was broad discomfort
with adopting the proposal for C2X because of the absence of
implementation experience and concerns raised by implementers.
The guidance to the study group was to target a separate technical
specification for the proposal and allow time for implementation
experience.  If the feedback from implementers is positive
(whatever that might mean) WG14 said it would consider adopting
the model for a revision of C after C2X.

Overall, the impact of the proposals as well as their goal is to
constrain implementations to the (presumed) benefit of programs
in terms of expressiveness.  There are numerous examples of code
that's currently treated as undefined by one or more compilers
(as a consequence of optimizations) that the model makes valid.
I'm not aware of any optimization opportunities the proposal
might open up in GCC.

Martin