[PATCH] D71224: [analyzer] Escape symbols stored into specific region after a conservative evalcall.

Tue Dec 10 14:00:44 PST 2019

xazax.hun added a comment.

In D71224#1778231 <https://reviews.llvm.org/D71224#1778231>, @NoQ wrote:

> In D71224#1778204 <https://reviews.llvm.org/D71224#1778204>, @xazax.hun wrote:
>
> > I don't think this is a good enough model currently. The problem is that, it does not play well with annotations. E.g. the checker can see a symbol escaping, but it does not have a whole lot of information how. For example, currently, there is no way to check if the output parameter through which the escape happened was annotated somehow.
>
>
> Hmm. If the function is annotated, it is hopefully "fully" annotated, or at least the programmer doesn't mind adding more annotations to it. Given that you have your `CallEvent` structure in `checkPointerEscape`, i hope you can easily see if there are any annotations at all on the function, and if so, suppress the current escape entirely. Or at least scan the annotated parameters and suppress the escape for them.
>
> I guess it's still a problem if the *same* handle is also passed through a parameter that *cannot* be annotated (eg., as part of a structure passed into the call) and then actually getting released inside the call, but is it a real problem for you?

Yeah, this was one of my idea as well. I think one of my main concerns is that I would except the majority of the escapes are simply being output parameters and only a minority are legitimate. So I was wondering if we got the default right. Maybe a checker should do more work to get the escaping rather than more work preventing it?

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71224/new/

https://reviews.llvm.org/D71224