[cfe-dev] [Analyzer] Pointer escape vs. pointer invalidation on function call

[Artem Dergachev via cfe-dev]

+Devin.

Yep, this behavior can be improved quite a bit. It's indeed overly 
conservative to believe that a single escaping pointer argument would 
cause other const pointer arguments' pointed-to regions invalidated.

argumentsMayEscape() should still be relied upon, it seems, because it 
contains a nice blacklist of weird functions, eg. 
https://stackoverflow.com/questions/7726329/what-is-the-purpose-of-const-pointer-to-void/7726359

However, making argumentsMayEscape() more fine-grained, eg. letting it 
provide a list of arguments that may escape, should be quite an improvement.

Additionally, when structures are passed into functions, we could 
consider const-qualifiers on pointer fields in these structures and 
avoid invalidating through pointers stored in const-pointer fields - 
might be an improvement as well. Direct parameters are not special.

Possible aliasing between arguments should still be taken into account, 
eg. tests with testMixedConstNonConstCalls() added in 
https://reviews.llvm.org/D19057 should remain "UNKNOWN". So i'd imagine 
a two-pass procedure, where on the first pass we mark base regions of 
all const pointers passed into the function with TK_PreserveContents, 
and on the second pass we remove TK_PreserveContents from base regions 
of non-const pointers.

Finally, i agree that argumentsMayEscape() makes sense for plain C 
system library functions only. It should ideally check that the function 
is within the standard library, and is a plain-C function, and avoid 
jumping to conclusions if this is not the case.


25/05/2017 8:07 PM, Aleksei Sidorin wrote:
> Hi all,
>
> I have some questions about CSA invalidation behaviour for the case 
> where some arguments can escape after call.
>
> 1. There is a condition in CallEvent::invalidateRegions():
>
>   if (!argumentsMayEscape())
>     findPtrToConstParams(PreserveArgs, *this);
>
> The contents of PreserveArgs changed by findPtrToConstParams() is used 
> later for setting a special invalidation trait for its items: 
> TK_PreserveContents. But, as I understand, if some pointer passed to 
> function can escape, all the pointers passed to function get 
> invalidated independently on can they escape or not. Why we don't just 
> filter the escaping regions and invalidate them but invalidate all the 
> pointers instead?
>
> 2. For AnyFunctionCall, we think that void* arguments of can escape:
>
>   if (CallEvent::argumentsMayEscape() || hasVoidPointerToNonConstArg())
>     return true;
>
> But because of (1), this means that all other pointers passed to such 
> function (including pointers to const) are invalidated. Checkers that 
> use argumentsMayEscape() method explicitly check that the call is 
> located in system header. So, should we move the check for system 
> header into argumentsMayEscape()? It looks like the commit that 
> introduced this behaviour was targeting system header functions only. 
> And should we avoid the invalidation of pointers to constant memory if 
> some pointer argument can escape?
>