Static analyzer: check for ForStmt

Clang Frontend
1

Hello,
I am new to the static analyzer codebase and wanted to try out some simple checkers on for loops. I noticed that PreStmt ignores control flow e.g. IfStmt and we should be using check::BranchCondition. I tried using check::BranchCondition on for loops and looks like it calls the checkBranchCondition function 4 times for 1 for loop. So,
  (1) Is this a bug?
  (2) Is check::BranchCondition the right checker to use here?

Thanks.

Sample for loop:

2

Siraj,

What you are seeing is expected - the analyzer processes entrance to the loop 4 times along the execution path.

What is the check you are trying to write? Is it path-sensitive in nature?

Cheers,
Anna.

3

Anna,
Thanks for your reply. I am looking at existing bugzilla entries and picked up http://llvm.org/bugs/show_bug.cgi?id=5067.

I started off with an AST based checker but soon realized that the iterators in the condition might be declared/assigned outside of the loop header (possibly outside of the current translation unit). I understand that currently the analyzer is limited to a single translation unit and won't detect this if not in the same TU.

Is it safe to cache the analyzed Stmt into a registered list so that we don't analyze the same Stmt 4 times? Thanks.

4

Anna,
Thanks for your reply. I am looking at existing bugzilla entries and picked up http://llvm.org/bugs/show_bug.cgi?id=5067.

I started off with an AST based checker but soon realized that the iterators in the condition might be declared/assigned outside of the loop header (possibly outside of the current translation unit). I understand that currently the analyzer is limited to a single translation unit and won’t detect this if not in the same TU.

You can just look for cases where you see the initialization of the iterators. That would be the majority of cases anyway.

Is it safe to cache the analyzed Stmt into a registered list so that we don’t analyze the same Stmt 4 times? Thanks.

The visited Stmt can be cached in the state.
However, note that the initialization happens only once per loop. You might want to check that the iterators from the same collection are compared each time. I am not sure if it would be much slower than checking if you’ve visited the for loop Stmt before and this would catch (though unlikely) cases where an iterator has been changed by one of the earlier loop iterations…

Anna.

5

Thanks for the reply. Is there an easy way to find out where a SVal was initialized/assiged to the last time? I am looking at CheckerContext::getLocationRegionIfPostStore() but not sure what I should pass as the ExplodedNode. Thanks.

6

I am having problems getting the SymRef from the SVal for the iterators. For some reason, they come up to be null.

const DeclRefExpr *It = …;
SVal ItVal = State->getSVal(It, C.getLocationContext()); //
SymbolRef ItSym = ItVal.getAsSymbol(); // This returns NULL

Is this the correct way to get the symbol from a SVal? Thanks.

7

I am having problems getting the SymRef from the SVal for the iterators. For some reason, they come up to be null.

const DeclRefExpr *It = …;
SVal ItVal = State->getSVal(It, C.getLocationContext()); //
SymbolRef ItSym = ItVal.getAsSymbol(); // This returns NULL

Is this the correct way to get the symbol from a SVal? Thanks.

Yes, that’s the right way to get a symbol from an SVal.

The reason why you are not getting a symbol is that the iterators are value objects, so if I am correct, you don’t get a symbol when one gets created. You can dump out the SVal and see what it is.

Because of this the iterators checker is an uncharted territory. We would greatly benefit from having it, but if you don’t have any experience with the analyzer, you might want to pick up some other task to get your feet wet first.

Cheers,
Anna.