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

[Anna Zaks]

> On Mar 20, 2015, at 2:44 PM, Adam Romanek <romanek.adam at gmail.com> wrote:
> 
> On 17.03.2015 14:16, Manuel Klimek wrote:
>> On Tue, Mar 17, 2015 at 1:52 PM Adam Romanek <romanek.adam at gmail.com
>> <mailto:romanek.adam at gmail.com>> wrote:
>> 
>>    Could you be more specific about these limitations of the engine? Are
>>    they documented somewhere?
>> 
>> 
>> Not that I'm aware of. The analyzer works well for a large set of code,
>> and people like us for whom it doesn't work well enough yet don't use it.
> 
> Well, as I indicated at the beginning, I use it all the time. I'm just trying to collect the knowledge required to push it towards C++ a bit further.
> 

The impact of the limitations in the core analysis depend on the codebase, so you might see less of these than Manuel. However, the main reason we do not have a lot of C++ specific checks is that C++ support was a relatively recent addition and is still lagging behind.

For example, we still get a few false positives on the LLVM codebase.

>> 
>>    Are there any plans or ongoing work on
>>    getting rid of them?
>> 
>> 
>>  It's an open source project, so help is always welcome :)
> 
> This is exactly why I started this conversation. I plan to contribute, I just don't want to waste my time and end up in a dead end.
> 
> Thanks,
> Adam Romanek
> 
>> 
>> 
>>    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>
>>     > <mailto: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?
>>     >

Pushing forward the work on body farms and using that to model string APIs sounds like a good direction. As others mentioned, you'd only need to model as much as needed by your checker. For example, to make sure that it understands the string APIs that "use and free". You might also want to add models that would tell the checker that the certain APIs do not change the state. I would start with a fresh new checker rather than extending malloc. You might need to work on improving Body Farm support as you go since we had not used it much before.

Iterator invalidation checker is also interesting. (I recall starting the work on it and running into some issues with tracking temporaries.)

Neither of these are trivial projects but both are valuable.
Anna.

>>     >     Thanks in advance.
>>     >
>>     >     Best regards,
>>     >     Adam Romanek
>>     >     ___________________________________________________
>>     >     cfe-dev mailing list
>>     > cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>    <mailto: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>
>>     >     <http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-dev
>>    <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>>
>>     >
>> 
>>    _________________________________________________
>>    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>
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev