On Wed, 17 Apr 2019 at 15:12, Uecker, Martin <martin.uec...@med.uni-goettingen.de> wrote: > > Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener: > > On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin > > <martin.uec...@med.uni-goettingen.de> wrote: > > > > > > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener: > > > > On Wed, Apr 17, 2019 at 1:53 PM Uecker, Martin > > > > <martin.uec...@med.uni-goettingen.de> wrote: > > > > > > > > > > > Since > > > > > > your proposal is based on an abstract machine there isn't anything > > > > > > like a pointer with multiple provenances (which "anything" is), just > > > > > > pointers with no provenance (pointing outside of any object), right? > > > > > > > > > > This is correct. What the proposal does though is put a limit > > > > > on where pointers obtained from integers are allowed to point > > > > > to: They cannot point to non-exposed objects. I assume GCC > > > > > "anything" provenances also cannot point to all possible > > > > > objects. > > > > > > > > Yes. We exclude objects that do not have their address taken > > > > though (so somewhat similar to your "exposed"). > > > > > > Also if the address never escapes? > > > > Yes.
Just for reference, here's Richard's above example in Cerberus, changed slightly so the Cerberus default allocator puts b after a, One can step through to see that this execution is allowed. https://cerberus.cl.cam.ac.uk/?short/9b83be > Then with respect to "expose" it seems GCC implements > a superset which means it allows some behavior which > is undefined according to the proposal. So all seems > well with respect to this part. y For the float thing (which is truly horrible :-), that reinterpretation of a pointer value as two floats would also (in our terms) expose the pointer, so the conversion the other way would just work. > With respect to tracking provenance through integers > some changes might be required. > > Let's consider this example: > > int x; > int y; > uintptr_t pi = (uintptr_t)&x; > uintptr_t pj = (uintptr_t)&y; > > if (pi + 4 == pj) { > > int* p = (int*)pj; // can be one-after pointer of 'x' > p[-1] = 1; // well defined? > } > > If I understand correctly, a pointer obtained from > pi + 4 would have a "anything" provenance (which is > fine). But the pointer obtained from 'pj' would have the > provenance of 'y' so the access to 'x' would not > be allowed. But according to the preferred version of > our proposal, the pointer could also be used to > access 'x' because it is also exposed. That's an interesting example. Here's a live version in Cerberus, which shows (at step 19) the ambiguous provenance of the result of the (int*) cast, resolved in the next steps by the pointer subtraction. https://cerberus.cl.cam.ac.uk/?short/a23efd So it's allowed in PNVI-ae-udi. For interest, PNVI-plain makes this UB (as one can see by changing the selected option under the Model dropdown). > GCC could make pj have a "anything" provenance > even though it is not modified. (This would break > some optimization such as the one for Matlab.) > > Maybe one could also refine this optimization to check > for additional conditions which rule out the case > that there is another object the pointer could point > to. > > Best, > Martin
