[PATCH] D60047: [CaptureTracking] Don't let comparisons against null escape inbounds pointers
Sanjoy Das via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 9 21:42:47 PDT 2019
sanjoy added a comment.
In D60047#1495488 <https://reviews.llvm.org/D60047#1495488>, @jdoerfert wrote:
> In D60047#1495432 <https://reviews.llvm.org/D60047#1495432>, @aqjune wrote:
>
> > Hello,
> >
> > > One mode of reasoning that could invalidate this example is that p *could have been* something other than 2^64-4 which would invoke UB. This UB would both let us pretend that foo does not escape p, and also print 2^64-4 even though p was not 2^64-4 in the execution we chose. This seems a bit subtle though, and I'm not entirely sure this is sound reasoning.
> >
> > (sorry for my sudden interruption :)
>
>
> That is what I did to re-start the discussion on this thread as well...
>
> > I think this reasoning makes sense, but to say why it makes sense a few minor details should be explained.
> > [...]
> > I think the story is similar here. We can define that the address of allocation is nondeterministically chosen (like the case of a racy program), so LLVM can pick the most problematic one, and say that the source program already has undefined behavior. :)
>
> Cool. @sanjoy, are we in agreement?
Yes, this sounds fine.
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D60047/new/
https://reviews.llvm.org/D60047
More information about the llvm-commits
mailing list