<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Le 13 janv. 2012 à 23:28, Anna Zaks a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Having annotations is something we are definitely interested in. <br><br>I think, one reason why we still do not have them is that designing expressive enough annotations is not a trivial task. Writing an effective checker for the most popular functions first would provide feedback on what they should be.<br><br>Do you have examples on the specific scenarios on what you'd like to annotate (or are you mostly talking about the malloc/free like pairs)?<br></div></blockquote><div><br></div><div>AFAIk, if this is for malloc/free pairs, you can use the ownership attributes (ownership_holds, ownership_returns, ownership_takes).</div><div><br></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><span style="color: #c22a9c">void</span> __attribute((ownership_returns(malloc))) *malloc(size_t);</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><span style="color: #c22a9c">void</span> __attribute((ownership_takes(malloc, <span style="color: #2f2fcf">1</span>))) free(<span style="color: #c22a9c">void</span> *);</div></div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><font class="Apple-style-span" face="Helvetica" size="3"><span class="Apple-style-span" style="background-color: transparent;">If you have your own allocator that is not malloc based, you can use an other identifier.</span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><font class="Apple-style-span" color="#c22a9c"><span class="Apple-style-span" style="background-color: transparent;">void</span></font><span class="Apple-style-span" style="background-color: transparent;"> __attribute((ownership_returns(my_pool))) *my_malloc(size_t);</span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; "><font class="Apple-style-span" color="#c22a9c"><span class="Apple-style-span" style="background-color: transparent;">void</span></font><span class="Apple-style-span" style="background-color: transparent;"> __attribute((ownership_takes(my_pool, 1))) my_free(</span><font class="Apple-style-span" color="#c22a9c"><span class="Apple-style-span" style="background-color: transparent;">void</span></font><span class="Apple-style-span" style="background-color: transparent;"> *);</span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 11px/normal Menlo; font-family: Helvetica; font-size: medium; "><br></div></div></div><blockquote type="cite"><div><br>Thanks,<br>Anna.<br>On Jan 13, 2012, at 10:55 AM, Ahmed Charles wrote:<br><br><blockquote type="cite">Slightly off topic, but something I've been wondering for a while.<br></blockquote><blockquote type="cite">Without actually investing this, but instead just reading the list, it<br></blockquote><blockquote type="cite">seems that most of the checkers that are written are specific to known<br></blockquote><blockquote type="cite">functions. For example, the malloc checker works for known allocation<br></blockquote><blockquote type="cite">functions rather than arbitrary ones. Is there a reason why there isn't<br></blockquote><blockquote type="cite">an effort to make this more extensible so that any function that is<br></blockquote><blockquote type="cite">annotated to be an allocation function can benefit from the malloc<br></blockquote><blockquote type="cite">checker (other than the obvious issue of resources and prioritization)?</blockquote></div></blockquote><blockquote type="cite"><div><blockquote type="cite">And similar for other checkers. I'm mostly interested in why this<br></blockquote><blockquote type="cite">possibility is never explicitly talked about.<br></blockquote><blockquote type="cite">From: Ted Kremenek<br></blockquote><blockquote type="cite">Sent: 1/11/2012 9:08 PM<br></blockquote><blockquote type="cite">To: Tom Care<br></blockquote><blockquote type="cite">Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br></blockquote><blockquote type="cite">Subject: Re: [cfe-dev] C++ analysis priorities<br></blockquote><blockquote type="cite">On Jan 11, 2012, at 5:47 PM, Tom Care wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi all,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">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.)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Tom<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Hi Tom,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I see that C++ support can grow in largely two directions:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(1) Core infrastructure, with interprocedural support for inlining C++<br></blockquote><blockquote type="cite">constructors/destructors to support RAII. This entails a bunch of<br></blockquote><blockquote type="cite">intermediate infrastructure work to get there.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(2) Checkers. Having C++-specific checkers will make the analyzer<br></blockquote><blockquote type="cite">more useful for C++ developers. This could be as simple as catching<br></blockquote><blockquote type="cite">mismatches between new[] and delete/new and delete[], and many others,<br></blockquote><blockquote type="cite">including providing checkers for correct usage of widely used C++ APIs<br></blockquote><blockquote type="cite">(e.g., Boost).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think both are worth making progress on, and to do (2) some progress<br></blockquote><blockquote type="cite">will likely need to be made on (1).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As far as infrastructure work, here are some areas that need work:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(a) Better representation of C++ constructor and destructor calls in<br></blockquote><blockquote type="cite">the CFG. There is a bunch already there, but as it has been observed<br></blockquote><blockquote type="cite">on the list lately there are serious deficiencies and outright bugs.<br></blockquote><blockquote type="cite">Ideally we should be able to represent the complete initialization<br></blockquote><blockquote type="cite">logic of a constructor in the CFG, from calling the constructor of a<br></blockquote><blockquote type="cite">parent class to correctly sequencing the initializers.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Along this trajectory, there are various optimizations we can do to<br></blockquote><blockquote type="cite">the CFG representation itself to make it easier to represent<br></blockquote><blockquote type="cite">destructor calls. What we do know is a bit complicated, IMO.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(b) ExprEngine "inlining" support for C++ constructors/destructors.<br></blockquote><blockquote type="cite">Interprocedural analysis is one area we would like to grow the<br></blockquote><blockquote type="cite">analyzer, and one technique to do that is to simply "inline" function<br></blockquote><blockquote type="cite">calls for function bodies that are available. Some of this has been<br></blockquote><blockquote type="cite">prototyped in the analyzer already, and there is currently work on<br></blockquote><blockquote type="cite">making it more solid, at least for inlining simple functions. Being<br></blockquote><blockquote type="cite">able to do this *well* for simple C++ objects that are used for RAII,<br></blockquote><blockquote type="cite">for example, will be really critical for making some checkers really<br></blockquote><blockquote type="cite">shine for C++.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(c) Support for additional C++ expressions. In ExprEngine::Visit(),<br></blockquote><blockquote type="cite">you can see a whole bunch of C++ AST expression kinds that are simply<br></blockquote><blockquote type="cite">not handled, and halt static analysis altogether:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> case Stmt::CXXBindTemporaryExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXCatchStmtClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXDependentScopeMemberExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXPseudoDestructorExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXThrowExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXTryStmtClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXTypeidExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXUuidofExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXUnresolvedConstructExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXScalarValueInitExprClass:<br></blockquote><blockquote type="cite"> case Stmt::DependentScopeDeclRefExprClass:<br></blockquote><blockquote type="cite"> case Stmt::UnaryTypeTraitExprClass:<br></blockquote><blockquote type="cite"> case Stmt::BinaryTypeTraitExprClass:<br></blockquote><blockquote type="cite"> case Stmt::ArrayTypeTraitExprClass:<br></blockquote><blockquote type="cite"> case Stmt::ExpressionTraitExprClass:<br></blockquote><blockquote type="cite"> case Stmt::UnresolvedLookupExprClass:<br></blockquote><blockquote type="cite"> case Stmt::UnresolvedMemberExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXNoexceptExprClass:<br></blockquote><blockquote type="cite"> case Stmt::PackExpansionExprClass:<br></blockquote><blockquote type="cite"> case Stmt::SubstNonTypeTemplateParmPackExprClass:<br></blockquote><blockquote type="cite"> case Stmt::SEHTryStmtClass:<br></blockquote><blockquote type="cite"> case Stmt::SEHExceptStmtClass:<br></blockquote><blockquote type="cite"> case Stmt::SEHFinallyStmtClass:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Further, there are some AST expressions we handle, but don't do a good job:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> // We don't handle default arguments either yet, but we can fake it<br></blockquote><blockquote type="cite"> // for now by just skipping them.<br></blockquote><blockquote type="cite"> case Stmt::SubstNonTypeTemplateParmExprClass:<br></blockquote><blockquote type="cite"> case Stmt::CXXDefaultArgExprClass:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">and support for C++ lambdas as they become real in Clang.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Infrastructure is only part of the story; ultimately people want to<br></blockquote><blockquote type="cite">find bugs. Some possible checkers include:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(1) mismatched new/delete[] new[]/delete, or malloc() and delete, etc.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(2) productizing the invalid iterator checker<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(3) making sure a destructor blows away everything a constructor<br></blockquote><blockquote type="cite">creates/initializes. This is a hard one, but could be REALLY useful<br></blockquote><blockquote type="cite">if done well. This could easily take up a good portion of your thesis<br></blockquote><blockquote type="cite">work, and would be interesting work to write about.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(4) Various checks for "Effective C++" rules.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(5) securely using std::string, i.e.<br></blockquote><blockquote type="cite"><a href="http://www.cert.org/archive/pdf/sd-bestpractices-strings060914.pdf">http://www.cert.org/archive/pdf/sd-bestpractices-strings060914.pdf</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(6) CERT's C++ secure coding standard,<br></blockquote><blockquote type="cite"><a href="https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637">https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=637</a>,<br></blockquote><blockquote type="cite">lots of potential checks here, not all of them specific to c++, but<br></blockquote><blockquote type="cite">general goodness.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite">Ted<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">cfe-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br></blockquote><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">cfe-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br></blockquote><blockquote type="cite"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br></blockquote><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></div></blockquote></div><br><div apple-content-edited="true">
<div>-- Jean-Daniel</div><div><br></div><div><br></div><br class="Apple-interchange-newline">
</div>
<br></body></html>