[cfe-dev] Clang Static Analyzer without scan-build

Aditya Kumar hiraditya at codeaurora.org
Wed Jul 31 12:07:19 PDT 2013


Thanks you for your feedback.

I tried scan-build for our codebase. The problem with scan-build is that it
has to be customized for every build-system and it becomes very tricky with
for e.g., scons.

Additionally, scan-build just overrides the CC/CXX flag which is not a
robust approach in my opinion.

With the 'compiler-flag' based approach the overhead of tailoring the
static-analyzer's front end to every build system does not come.

The advantage of having a flag to do both the tasks at once is programmers
could do this several times (during the development process which I think is
the best time to solve a potential bug), possibly with a very limited set of
checkers.

 

Although, I'm not sure how the problem of cross TU analysis could be handled
using the 'compiler-flag' based approach. I'll have to think about it.

 

-Aditya

 

 

From: Anna Zaks [mailto:ganna at apple.com] 
Sent: Wednesday, July 31, 2013 1:08 PM
To: Aditya Kumar
Cc: cfe-dev at cs.uiuc.edu; m.galante at centrosistemi.it
Subject: Re: [cfe-dev] Clang Static Analyzer without scan-build

 

 

On Jul 30, 2013, at 2:37 PM, Aditya Kumar <hiraditya at codeaurora.org> wrote:





I was looking at the same problem and planning to work on it.

What I'm planning to do is having a compiler flag which enables a user to
perform compilation as well as static analysis at the same time,

and make relevant changes in the clang driver to build a set of 'Actions' in
the pipeline such that static analysis and compilation takes place
simultaneously.

This will have an overhead on the overall compilation time which is often
not the desirable thing. But there is an advantage that this flag can be
incorporated in the build-system of software.

Since the build systems are really good at tracking the files which have
changed and compiling only the minimal set of required files,

the overall turnaround time of static analysis will be very small and user
can afford to run static analyzer with every build.

 

Have you looked at how scan-build currently works? It does compile and
analyze the source files (clang is called twice). It is also driven by the
build system, so we are not reanalyzing files that the build system would
not recompile.

 

The main advantage of keeping the scan-build-like interface is that, in the
future, we plan to extend the analyzer to perform cross-file(translation
unit) analysis. This is why we encourage the use of a single entry point
(scan-build) when analyzing a project.

 

Said that, the current implementation of scan-build is hacky and could be
improved (see http://clang-analyzer.llvm.org/open_projects.html).

 

Cheers,

Anna.





 

I wanted some feedback if this is a good idea or not.

 

-Aditya

_______________________________________________
cfe-dev mailing list
 <mailto:cfe-dev at cs.uiuc.edu> cfe-dev at cs.uiuc.edu
 <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130731/56bd729d/attachment.html>


More information about the cfe-dev mailing list