[cfe-dev] [RFC] Creating base class for 'Test after X' checkers

Daniel Marjamäki Daniel.Marjamaki at evidente.se
Thu Aug 28 01:29:01 PDT 2014


Hello!

I want to have path-sensitive analysis. However I do not understood how it's done effectively in Clang yet. It's quite different to Cppcheck. :-)

> My understanding is that you are working around this by performing checking within a single basic block

The problem is mostly that I don't understand how CFG is used effectively. I don't see how to properly handle inner/outer/same scope.

> I think it’s best to write these as non-path sensitive data flow analysis on the CFG. What do you think?

sorry.. could you be more specific. do you want to move the checker. do you want it to use a different visitor? do you want that we remove some logic?

best regards,
Daniel Marjamäki

..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden

Mobile:                 +46 (0)709 12 42 62
E-mail:                 Daniel.Marjamaki<mailto:Daniel.Marjamaki at evidente.se>@evidente.se<mailto:Daniel.Marjamaki at evidente.se>

www.evidente.se
________________________________
Från: Anna Zaks [ganna at apple.com]
Skickat: den 27 augusti 2014 19:48
Till: Daniel Marjamäki
Cc: cfe-dev at cs.uiuc.edu; Jordan Rose
Ämne: Re: [cfe-dev] [RFC] Creating base class for 'Test after X' checkers

Hi Daniel,

As Jordan mentioned earlier, I am concerned about making test after div-zero/dereference checkers rely on path sensitive analysis. These require all path reasoning and the analyzer does not guarantee to cover all paths (some of them might be silently dropped). My understanding is that you are working around this by performing checking within a single basic block; however, in that case relying on the power of path sensitivity is an overkill. I think it’s best to write these as non-path sensitive data flow analysis on the CFG. What do you think?

If we decided to go with path-sensitive checkers for this, addition of the base class would be the right way to go.

On Aug 24, 2014, at 2:25 AM, Daniel Marjamäki <Daniel.Marjamaki at evidente.se<mailto:Daniel.Marjamaki at evidente.se>> wrote:

Hello!

Recently a TestAfterDivZero checker was added to the static analyser (r212731).

We could add many related checkers, for example:
 * test after null pointer dereference
 * test after array index out of bounds
 * test after dangerous/invalid function argument
 * ...

I wonder what you think about creating generic base classes for TestAfterX checkers. Would you prefer copy/paste?

I attach a proof of concept patch. It adds a include file llvm/tools/clang/include/StaticAnalyzer/Core/TestAfterChecker.h.

This one should be added under include/clang/StaticAnalyzer/Checkers/. See ObjCRetainCount.h as an example.

Is that the proper path where it should be or would it be better somewhere else? There is no implementation but I should add it in llvm/tools/clang/lib/StaticAnalyzer/Core/TestAfterChecker.cpp, shouldn't I? Do you have an opinion about the namespace usage?

It might still be possible to move some more code from the checker to the base classes. The current code is work-in-progress.

Best regards,
Daniel Marjamäki

..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden

Mobile:                 +46 (0)709 12 42 62
E-mail:                 Daniel.Marjamaki<mailto:Daniel.Marjamaki at evidente.se>@evidente.se<mailto:Daniel.Marjamaki at evidente.se>

www.evidente.se<http://www.evidente.se/>
_______________________________________________
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/20140828/fce2e72b/attachment.html>


More information about the cfe-dev mailing list