[cfe-dev] MallocChecker/RetainCountChecker bind symbol invalidation logic

Ted Kremenek kremenek at apple.com
Wed May 23 22:13:53 PDT 2012

On May 22, 2012, at 10:58 PM, Anna Zaks <ganna at apple.com> wrote:

>> Another example, and the one that brought this up: If we have a class field, then the symbol could be tracked until the field or the class escapes in a call.
> Malloc checker (possibly RetainCount as well) are not even this smart. We give up when a pointer is assigned to a field in a struct/class. We should associate the pointer with the struct/class object and assume that the pointer escapes when either the object or the pointer itself escape. We ran out of time implementing this one.

Adding to Anna's comment, the logic here is overly conservative until we do something smarter for modeling escaping memory in the core analyzer engine.

Essentially, this is a localized hack to avoid a potentially large source of false positives, but it is overly conservative.  The problem is that the right solution requires us having a general mechanism of "escaping" memory (as handled by ExprEngine) and then having checker callbacks to respond to such cases, just like we do for invalidating regions, etc.  Since that problem hasn't been tackled yet, this localized hack remains our safest option.  It absolutely doesn't belong in the checker in this form.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120523/d6e5e3b0/attachment.html>

More information about the cfe-dev mailing list