[cfe-dev] [StaticAnalyzer] C++ related checkers

[Adam Romanek]

Could you be more specific about these limitations of the engine? Are 
they documented somewhere? Are there any plans or ongoing work on 
getting rid of them?

Best regards,
Adam Romanek

On 17.03.2015 12:11, Manuel Klimek wrote:
> There are still a few core issues to resolve in the analyzer before
> it'll get really useful for large C++ codebases (<- opinion :) and I
> think that's why we're not seeing that many C++ related checks.
>
> Specifically, temporary constructors/destructors still have work to do,
> especially regarding passing temporaries as by-value function parameters.
>
> On Mon, Mar 16, 2015 at 11:22 PM Adam Romanek <romanek.adam at gmail.com
> <mailto:romanek.adam at gmail.com>> wrote:
>
>     Hi!
>
>     I'm new to this list and to Clang development. Nevertheless I've
>     been interested in Clang Static Analyzer for a while. I've been
>     using it on a large code base with a lot of success. So let me start
>     by saying: thanks for this amazing piece of code!
>
>     But... Some time ago I realized there are hardly any strictly C++
>     related checkers in CSA. I was wondering if there's any movement in
>     this area. I was thinking about some checkers for use-after-free for
>     STL containers like std::string, for example:
>
>     const char* x = NULL;
>     {
>        std::string foo("foo");
>        x = foo.c_str();
>     }
>     printf("%s", x); // boom
>
>     There are also some other common types of errors in C++ like use of
>     iterator after it has been invalidated. FYI this one in particular
>     is detected by cppcheck.
>
>     So I decided to dig a bit to find out whether it is hard to write a
>     checker for use-after-free like in the example with std::string. It
>     looks like MallocChecker deals with a similar class of issues.
>
>     I was wondering whether it would be the right approach to try to
>     "bend" MallocChecker to my needs (but it's already 2.5k lines of
>     code) or to start something new on my own.
>
>     Honestly it took me some time even to detect a simple std::string
>     constructor call so the road looks rather long and bumpy...
>
>     Any hints, pointers? Any related work?
>
>     Thanks in advance.
>
>     Best regards,
>     Adam Romanek
>     _________________________________________________
>     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
>     <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>