[cfe-dev] Removing "TransferFuncs" from the analyzer

[Ted Kremenek]

On Jul 14, 2011, at 10:21 PM, Ted Kremenek wrote:

>> - CFBugReports use function call summaries to show the retain/release history of a leaked object. Function summaries are currently associated with ExplodedNodes in a DenseMap. In addition to being somewhat inefficient (summaries for calls that have nothing to do with ref-counting are also saved), Checkers are const, and so can't store summaries in a mutable data structure. (Marking the map 'mutable' doesn't feel like the right solution.) I don't have a solution for this.
> 
> I don't actually see an issue here, but I recognize your concerns.  Let's separate your two statements.
> 
> First, the primary and original role of the function summaries is to memoize the behavior of a function/method call for quick application during evalCall.  It's a computational hack.  I should add that Checkers are not strictly const.  They are allowed to contain data.  What they shouldn't record is data specific to analyzing a given function or path.  All that data should be in GRState. There is no reason, however, that Checkers cannot have any on-the-side data to cache computation that they do over and over again, particularly if it has nothing to do with a specific path.

One amendment: I do recognize that the checker call backs are currently marked 'const'.  I took this road to enforce a mentality that the checker writers should think about keeping state in GRState, and not in the checker itself.  First-time checker writers often don't understand why keeping information specific to a path in GRState is so critical.  This decision can always be revisited.

My point, however, was that the idea of keeping data associated with a Checker is not strictly taboo if done correctly.  If we want to enforce the 'const'ness strictly, then it may be worthwhile to provide checkers a way to store other side data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110715/c4e95b3e/attachment.html>