[cfe-dev] Prevent RetainCountChecker from Analyzing Function Bodies when They Have Certain Annotate Attribute

[Devin Coughlin via cfe-dev]

> On Jul 10, 2017, at 6:26 AM, Malhar Thakkar via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Dear Dr. Alexandre,
> 
> The leak warning is raised by MallocChecker and not the RetainCountChecker (which performs reference counting).
> Adding 'rc_ownership_trusted_implementation' annotation to 'bar' and returning true (successfully evaluating 'bar') from evalCall() callback in RetainCountChecker prevents the analyzer from analyzing bar's body. This causes problems for the MallocChecker as it is unable to find a call to 'free' for the call to 'malloc' in foo().

How does allocation work in ISL? Are data structures allocated through library-provided functions that create an instance of the data structure? Or does client code call malloc() directly? If the first, the library-provided allocations functions could also be annotated a trusted. Then, if these are annotated they won’t be inlined and the malloc checker won’t see the malloc site — so there won’t be a diagnostic about a leak.


> Using evalCall(), we'll be able to suppress leak false positives raised in ISL due to obj_free(), obj_cow() and obj_copy(). Now, we want our solution (to suppress such false positives) to be as generalized as possible. By generalized, I mean using the same "trusted" annotation across different codebases.
> However, this approach (using evalCall()) can't be generalized for other codebases in C as it's possible for some codebase to have code similar to the one mentioned in my previous email. Such a test-case will result in the MallocChecker raising false positives.

Can you give a specific example of the problem you are envisioning with evalCall()? Are you worried about other checkers wanting to also evaluate the call?

Devin