[LLVMbugs] [Bug 7492] New: Make use of static-analysis annotations to guide static analyzer

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Jun 25 04:43:52 PDT 2010


           Summary: Make use of static-analysis annotations to guide
                    static analyzer
           Product: clang
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: pgut001 at cs.auckland.ac.nz
                CC: llvmbugs at cs.uiuc.edu

There are a number of bugs and feature requests that I think could be solved by
a single enhancement involving recognising static-analysis annotations.  For
example bug #2650 "Need a way to mark code to hush-up Static Analyzer for
specific instances" could be resolved through the SAL annotation

__analysis_assume( foo != NULL );

which would guide the analyser by indicating that the pointer at this location
isn't NULL (or, in general, any expression you want).  I'm using SAL in this
case because that's by far the best-developed of the analyser annotation
mechanisms.  To make this portable you'd use:

#ifdef __clang_analyzer__
  #define ANALYSIS_ASSUME( x ) __analysis_assume( x )
  #define ANALYSIS_ASSUME( x )

Bug 7926 "Disable specific warnings during static analysis" is another bug
that'd be resolved by this.  And 2900.  And 4832.  And possibly 2769.  And I'm
sure there are others, I've stopped looking :-).  Some useful annotations would

__analysis_assume( expr ) - See above.
__nonnull - This function arg should never be called with a NULL pointer (gcc
implements this, but gets it wrong).
__checkreturn - This function return value must always be used (gcc also gets
this one wrong).
__dead( variable ) - This variable is now dead (e.g. after a dealloc function
is called on it), any use of it beyond this point is an error. This is
desperately needed to catch dangling refs, double frees, etc.
__success( value ) - Indicates what the function returns on success.  My
biggest source of false positives with the clang analyzer has been code like:

  status = foo( &val );
  if status == error
  do_thing( val );

because the analyzer doesn't know that do_thing() will only get called if
status != error, and so doesn't need to warn about val not being initialised. 
So the annotation is:

__success( status >= 0 ) int foo( ... );

and clang would then know that the 'status == error' check would only be passed
if the __success criterion was met, and that val would be initialised at that

I've been working with static code analysis tools for some time, I have a fair
bit of experience with what's useful, and also a long wishlist... I'd really
kill for a __dead() ability for example, no existing analyser that I know of
(Coverity, Fortify, PREfast, Klocwork) has this.

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list