[cfe-commits] r150112 - in /cfe/trunk: lib/StaticAnalyzer/Checkers/MallocChecker.cpp test/Analysis/malloc.c

[Ted Kremenek]

On Feb 8, 2012, at 3:37 PM, Anna Zaks <ganna at apple.com> wrote:

> 
> On Feb 8, 2012, at 3:25 PM, Ted Kremenek wrote:
> 
>> On Feb 8, 2012, at 3:16 PM, Anna Zaks <ganna at apple.com> wrote:
>> 
>>> Author: zaks
>>> Date: Wed Feb  8 17:16:56 2012
>>> New Revision: 150112
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=150112&view=rev
>>> Log:
>>> [analyzer] MallocChecker: implement pessimistic version of the checker,
>>> which allows values to escape through unknown calls.
>>> 
>>> Assumes all calls but the malloc family are unknown.
>> 
>> One nit: we should only do this if the call was not inlined.  Otherwise we're being overly pessimistic.
> 
> Shouldn't inlining be transparent to the checkers?

It should be transparent, but checkers should not be ignorant of its implications.

> Ex: Should the checkers receive the post/pre visit callbacks on a CallExpr if it's being inlined?

Absolutely.  The pre- and post- visit checks are for checking preconditions and postconditions, which is orthogonal to how the actual function call gets evaluated.

This is probably worth some design discussion.

> Another concern I wanted to raise is that I've renamed the optimistic(old) checker to MallocWithAnnotationsd and named the new checker Malloc. I think the naming makes sense, but not sure if we are going to effect existing users of the old Malloc checker.

Since the old checker behavior wasn't widely published (and the checker was "experimental" on top of that) I think this is fine.  Existing users can migrate with little difficulty.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120208/42cc06da/attachment.html>