[cfe-dev] Analysis support for C++

[Marcin Świderski]

W dniu 25 maja 2010 20:09 użytkownik Ted Kremenek <kremenek at apple.com>napisał:

> On May 23, 2010, at 5:40 PM, Marcin Świderski wrote:
>
> Hi,
>
> I'm interested in working on support for C++ in Static Analyzer project (or
> is it Checker now?). I would like to use this in my master thesis so I want
> to do as much as I can in  two or three months. I'm planning on working on
> this on daily basis during this time. I think I will continue to contribute
> later on, but time will show.
>
> Of cource I have some questions, so here they are:
>
> 1. On http://clang-analyzer.llvm.org/dev_cxx.html there's a list of what
> has to be done. Is this list up to date? Or did someone done some of these
> tasks already?
>
> 2. Assuming that I have to get to know the project and probably widen my
> knowledge on static code analysis what can I accomplish in time of two/three
> months?
>
> 3. The xcode project in svn is terribly out of sync. I'm really not used to
> working on large scale projects without IDE so will probably set up my own
> project base on the one from svn. However maybe someone has an up to date
> xcode project and could share it?
>
> I will also appreciate any advice you can give me. This is the first open
> source project I will work on so I will probably need some.
>
>
> Hi Marcin,
>
> The list of things to be done is mostly up-to-date, but really only touches
> on a fraction of what needs to be done to build a great static analysis tool
> for C++.  However, the tasks listed there are great starting points for
> bringing up basic functionality.  The CFG related pieces in particular would
> also benefit the compiler as well, as the CFG is now used for some warnings.
>
> Some of the major pieces listed aren't conceptually novel, but require some
> time and diligence to implement well.  I think in 2-3 months someone new to
> the project could make some good progress on the CFG support (which is
> really vital) as well as implement some interesting checks.  Those initial
> checks don't even have to be path-sensitive (which requires extending
> GRExprEngine), as even some basic flow-sensitive checks (which use the CFG)
> could be very useful for finding bugs.  If you want to work on
> infrastructure, I think modeling scopes, destructors, and initializers in
> the CFG would be a great place to start, and I have some pointers and how
> this could be done.
>
> Another (probably simpler) place to start would be to think of some simple
> checks you would want to do that wouldn't require much analysis power at
> all, e.g. simple pattern matching on the ASTs.  Working on those kind of
> checks might be good enough to get your feet wet while not exposing you all
> at once to all the gnarly details of the analyzer.  For example, the checks
> in  LLVMConventionsChecker.cpp (which are custom checks for the LLVM
> codebase) are purely syntactic checks right now, but they use the same bug
> reporting apparatus as the more complicated checks.
>
> As for using Xcode for development, ass others commented, use CMake to
> generated an Xcode project.  For example:
>
> $ mkdir llvm-xcode
> $ cd llvm-xcode
> $ cmake -G Xcode ~/llvm
>
> (here I assume your llvm tree is in ~llvm)
>
> I personally would like to remove the old clang.xcodeproj, but others still
> use it for navigation.
>
> Cheers,
> Ted
>
Hi Ted,

Sorry for such a late answer. I will start to work on things you mentioned
about CFG.

1. Initializers:
Adding initializers should be fairly easy as there's even place marked for
this. For every member and base I should add a call to appropriate
constructor (if not trival?).

2. Scopes:
I see there's basic implementation that marks begin/end of scope based on
begin/end of compound statement. If I were to extend this implementation I
would:
    - add end scope markers after jumps out of scope,
    - add methods for working with scopes, e.g. check if some
variable/object is in scope.

3. Destructors:
Implementing destructors would involve adding statements for explicitly
calling destructors at:
    - for local varaibles at end of scopes,
    - in for base and members in destructor body?

Could you (or sombody else) comment on this please?

There's one thing connected with those subjects that comes to my mind:
temporaries. Shouldn't we add constructors/destructors and scopes (full
expressions) for those also?

Cheers
Sfider
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100715/ed8ef187/attachment.html>