[cfe-dev] C++ analysis priorities

[Ted Kremenek]

Hi Ahmed, 

As others pointed out, there is interest in this.  The analyzer already recognizes attributes in to extend its functionality, so when you speak about "annotations" it really depends on the scope of the work.

Designing a general annotation system is essentially language design.  It's a potentially worthy endeavor if it is well focused, but it is a big effort.  Instead, the focus on attributes has largely been demand driven, focusing on simple but well-defined objectives.  That negative of that approach is that it can be myopic, but it does result in progress.  A reasonable trajectory is to provide such focused annotations, and when a more general solution arises phase that old syntax out and replace with the newer syntax.  There are various rollout strategies for that approach.

Did you have a particular problem you were hoping to solve with annotations?  On one extreme, one could have an annotation system powerful enough to define checkers, and on the other extreme you can have annotations to handle spot issues.  There is plenty of interesting territory between those extremes.

Cheers,
Ted


On Friday, January 13, 2012 at 10:55 AM, Ahmed Charles wrote:

> Slightly off topic, but something I've been wondering for a while.
> Without actually investing this, but instead just reading the list, it
> seems that most of the checkers that are written are specific to known
> functions. For example, the malloc checker works for known allocation
> functions rather than arbitrary ones. Is there a reason why there isn't
> an effort to make this more extensible so that any function that is
> annotated to be an allocation function can benefit from the malloc
> checker (other than the obvious issue of resources and prioritization)?
> And similar for other checkers. I'm mostly interested in why this
> possibility is never explicitly talked about.
> From: Ted Kremenek
> Sent: 1/11/2012 9:08 PM
> To: Tom Care
> Cc: cfe-dev at cs.uiuc.edu (mailto:cfe-dev at cs.uiuc.edu)
> Subject: Re: [cfe-dev] C++ analysis priorities
> On Jan 11, 2012, at 5:47 PM, Tom Care wrote:
> 
> > Hi all,
> > 
> > I'm looking at possibly contributing to C++ analysis support over the next few months as part of a master's project. I have a rough idea of things that need to be implemented, but I am not sure how to prioritise them. I am hoping that the community can assist me here - what is currently stopping your programs from being analyzed?
> > 
> > My general goal is to implement features that will assist in analyzing the LLVM/Clang codebase, however looking at the current code it seems that existing support for some language features will have to be improved as well (eg ctor/dtors.)
> > 
> > Thanks,
> > 
> > Tom
> 
> Hi Tom,
> 
> I see that C++ support can grow in largely two directions:
> 
> (1) Core infrastructure, with interprocedural support for inlining C++
> constructors/destructors to support RAII. This entails a bunch of
> intermediate infrastructure work to get there.
> 
> (2) Checkers. Having C++-specific checkers will make the analyzer
> more useful for C++ developers. This could be as simple as catching
> mismatches between new[] and delete/new and delete[], and many others,
> including providing checkers for correct usage of widely used C++ APIs
> (e.g., Boost).
> 
> I think both are worth making progress on, and to do (2) some progress
> will likely need to be made on (1).
> 
> As far as infrastructure work, here are some areas that need work:
> 
> (a) Better representation of C++ constructor and destructor calls in
> the CFG. There is a bunch already there, but as it has been observed
> on the list lately there are serious deficiencies and outright bugs.
> Ideally we should be able to represent the complete initialization
> logic of a constructor in the CFG, from calling the constructor of a
> parent class to correctly sequencing the initializers.
> 
> Along this trajectory, there are various optimizations we can do to
> the CFG representation itself to make it easier to represent
> destructor calls. What we do know is a bit complicated, IMO.
> 
> (b) ExprEngine "inlining" support for C++ constructors/destructors.
> Interprocedural analysis is one area we would like to grow the
> analyzer, and one technique to do that is to simply "inline" function
> calls for function bodies that are available. Some of this has been
> prototyped in the analyzer already, and there is currently work on
> making it more solid, at least for inlining simple functions. Being
> able to do this *well* for simple C++ objects that are used for RAII,
> for example, will be really critical for making some checkers really
> shine for C++.
> 
> (c) Support for additional C++ expressions. In ExprEngine::Visit(),
> you can see a whole bunch of C++ AST expression kinds that are simply
> not handled, and halt static analysis altogether:
> 
> case Stmt::CXXBindTemporaryExprClass:
> case Stmt::CXXCatchStmtClass:
> case Stmt::CXXDependentScopeMemberExprClass:
> case Stmt::CXXPseudoDestructorExprClass:
> case Stmt::CXXThrowExprClass:
> case Stmt::CXXTryStmtClass:
> case Stmt::CXXTypeidExprClass:
> case Stmt::CXXUuidofExprClass:
> case Stmt::CXXUnresolvedConstructExprClass:
> case Stmt::CXXScalarValueInitExprClass:
> case Stmt::DependentScopeDeclRefExprClass:
> case Stmt::UnaryTypeTraitExprClass:
> case Stmt::BinaryTypeTraitExprClass:
> case Stmt::ArrayTypeTraitExprClass:
> case Stmt::ExpressionTraitExprClass:
> case Stmt::UnresolvedLookupExprClass:
> case Stmt::UnresolvedMemberExprClass:
> case Stmt::CXXNoexceptExprClass:
> case Stmt::PackExpansionExprClass:
> case Stmt::SubstNonTypeTemplateParmPackExprClass:
> case Stmt::SEHTryStmtClass:
> case Stmt::SEHExceptStmtClass:
> case Stmt::SEHFinallyStmtClass:
> 
> Further, there are some AST expressions we handle, but don't do a good job:
> 
> // We don't handle default arguments either yet, but we can fake it
> // for now by just skipping them.
> case Stmt::SubstNonTypeTemplateParmExprClass:
> case Stmt::CXXDefaultArgExprClass:
> 
> and support for C++ lambdas as they become real in Clang.
> 
> Infrastructure is only part of the story; ultimately people want to
> find bugs. Some possible checkers include:
> 
> (1) mismatched new/delete[] new[]/delete, or malloc() and delete, etc.
> 
> (2) productizing the invalid iterator checker
> 
> (3) making sure a destructor blows away everything a constructor
> creates/initializes. This is a hard one, but could be REALLY useful
> if done well. This could easily take up a good portion of your thesis
> work, and would be interesting work to write about.
> 
> (4) Various checks for "Effective C++" rules.
> 
> (5) securely using std::string, i.e.
> http://www.cert.org/archive/pdf/sd-bestpractices-strings060914.pdf
> 
> (6) CERT's C++ secure coding standard,
> https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637,
> lots of potential checks here, not all of them specific to c++, but
> general goodness.
> 
> Cheers,
> Ted
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu (mailto:cfe-dev at cs.uiuc.edu)
> 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/20120117/0a2c4017/attachment.html>