Re: C provenance semantics proposal

[Jeff Law <law@redhat.com>]

On 4/18/19 6:20 AM, Uecker, Martin wrote:
> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
>> On Thu, 18 Apr 2019 at 10:32, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> 
>> An equality test of two pointers, on the other hand, doesn't necessarily
>> mean that they are interchangeable.  I don't see any good way to
>> avoid that in a provenance semantics, where a one-past
>> pointer might sometimes compare equal to a pointer to an
>> adjacent object but be illegal for accessing it.
> 
> As I see it, there are essentially four options:
> 
> 1.) Compilers do not use conditional equivalences for
> optimizations of pointers (or only when additional
> conditions apply which make it safe)
I know this will hit DOM and CSE.  I wouldn't be surprised if it touches
VRP as well, maybe PTA.  It seems simple enough though :-)

> 
> 2.) We make pointer comparison between a pointer
> and a one-after pointer of a different object
> undefined behaviour.
I generally like this as well, though I suspect it probably makes a lot
of currently well defined code undefined.

> 
> 3.) We make comparison have the side effect that
> afterwards any of the two pointers could have any
> of the two provenances. (with disambiguitation
> similar to what we have for casts).
This could have some interesting effects on PTA.  Richi?


> 
> 4.) Compilers make sure that exposed objects never
> are allocated next to each other (as Jens proposed).
Ugh.  Not sure how you enforce that.  Consider that the compiler may
ultimately have no control over layout of data in static storage.

jeff