[cfe-dev] Analyzer discrepancy with __builtin_alloca

[Ted Kremenek]

Hi Austin,

The logic for __builtin_alloca is being handled by BuiltinFunctionChecker, which explicitly models the semantics of the function.  It does this by responding to 'evalCall()'.  That should not interfere with the checkPreStmt() callback in UnixAPIChecker, and if that is the case there is a bug here.

What is likely the case is that builtins are just modeled slightly differently in the AST.  I suggest that you take a look at BuiltinFunctionChecker for how we recognize calls to __builtin_alloca and see if that approach works for you.  In any case, please follow-up on the list to see if that fixes or doesn't fix the issue you are seeing.

Cheers,
Ted

On Jan 6, 2012, at 2:38 PM, austin seipp wrote:

> Hello,
> 
> I was working on adding alloca/valloc checks (as well as a small
> cleanup) to UnixAPIChecker following the recent changes to detect
> zero-sized allocations in calloc/realloc (SVN r147500,) when I noticed
> a strange issue when attempting to identify calls to __builtin_alloca.
> 
> 'alloca' seems to dissolve to __builtin_alloca via a CPP #define on OS
> X, so for the check to work and be 'complete' it needs to identify
> both names. However, it seems as if the checker callback -
> checkPreStmt on a CallExpr - is not invoked for calls to
> __builtin_alloca, but it does work just dandy in the case of say,
> __builtin_expect. So presumably I'm missing something important and
> it's expected behavior, or this is a bug I guess.
> 
> A little more concrete: I amended ./test/Analysis/unix-fns.c to
> contain calls for alloca - with a prototyped definition so there
> aren't complaints about implicit declarations - *and* calls to
> __builtin_alloca, both of which should trigger a 0-sized allocation
> warning. I also modified UnixAPIChecker to dump the name of every
> callee it comes across, or dump some trivial output if it skips the
> call due to getCalleeName returning an empty StringRef.
> 
> The results look like this on my machine:
> 
> $ /Users/a/code/llvm-build/Debug+Asserts/bin/clang -cc1
> -internal-isystem
> /Users/a/code/llvm-build/Debug+Asserts/bin/../lib/clang/3.1/include
> -triple x86_64-apple-darwin10 -analyze
> -analyzer-checker=unix.API,osx.API
> /Users/a/code/llvm/tools/clang/test/Analysis/unix-fns.c
> -analyzer-store=region -fblocks -verify
> fname = open
> fname = open
> fname = close
> fname = open
> fname = __builtin_expect
> fname = dispatch_once
> fname = __builtin_expect
> fname = dispatch_once
> fname = pthread_once
> fname = pthread_once
> fname = malloc
> fname = malloc
> fname = calloc
> fname = calloc
> fname = calloc
> fname = realloc
> fname = realloc
> fname = alloca
> fname = alloca
> fname = valloc
> fname = valloc
> 
> The calls to __builtin_alloca should effectively appear in the same
> spot as the 'alloca' calls, but they clearly aren't. There also isn't
> any 'no name' output indicating the call was skipped as a result of an
> empty StringRef from getCalleeName. So it seems as if checkPreStmt for
> a CallExpr completely skips over __builtin_alloca. The calls do appear
> in a dump of the CFG as you would likely expect.
> 
> Is __builtin_alloca handled specially in the analyzer somewhere, and
> thus I'm missing something? If it is and this is unavoidable, I'll
> just back out those changes and send a patch containing the valloc
> addition as well as the small cleanup if they're worth it. But I don't
> see off hand why it can't work for alloca as well, so I thought I'd
> ask.
> 
> -- 
> Regards,
> Austin
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev