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

[Tom Care]

Hi all,

In MallocChecker::checkBind and RetainCountChecker::checkBind we have logic to determine if a bind causes a symbol to escape. I was wondering why we require a symbol to have local storage, as it seems a bit conservative to me. Hopefully I understand this correctly...

For example: if we are binding to a global, we stop tracking immediately. It seems to me that we could still track the global symbol on the current path until we make a function call, at which point we can no longer assume we know the value.
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. There could be smart ways to track this, e.g field visibility, but the conservative way would be to assume that any call may result in access to the class. Most of the smart ways I can think of would require accurate inter-procedural analysis.

Perhaps we can allow for non-local storage to be continue to be tracked (subject to the other escaping rules) and then purge all non-local symbols when a call is made? Is there any other case where non-local storage could escape before a call?

class->foo = malloc(42); // continue tracking after bind
...
bar(class->foo); // escapes - trivial
bar(class); // escapes - bar might modify foo
class->method() //; escapes, unless method is const?
bar(); // escapes - conservative - bar may have class pointer

Tom