[cfe-dev] Static analyzer: check for ForStmt

[Anna Zaks]

On Jun 26, 2013, at 9:35 AM, "Siraj, Tareq A" <tareq.a.siraj at intel.com> wrote:

> 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.

> --
> Tareq A. Siraj 
> 
> On 2013-06-25, at 4:40 PM, "Siraj, Tareq A" <tareq.a.siraj at intel.com>
> wrote:
> 
>> 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.
>> 
>> --
>> Tareq A. Siraj 
>> 
>> 
>> On 2013-06-25, at 1:41 PM, Anna Zaks <ganna at apple.com>
>> wrote:
>> 
>>> 
>>> On Jun 25, 2013, at 10:28 AM, "Siraj, Tareq A" <tareq.a.siraj at intel.com> wrote:
>>> 
>>>> 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.
>>> 
>>>> 
>>>> --
>>>> Tareq A. Siraj 
>>>> 
>>>> 
>>>> On 2013-06-25, at 1:14 PM, Anna Zaks <ganna at apple.com>
>>>> wrote:
>>>> 
>>>>> 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.
>>>>> 
>>>>> On Jun 25, 2013, at 8:10 AM, "Siraj, Tareq A" <tareq.a.siraj at intel.com> wrote:
>>>>> 
>>>>>> 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:
>>>>>> =============
>>>>>> for (int i = 0; i < 10; ++i)
>>>>>> 
>>>>>> Calling dump() on the statement in checkBranchCondition() produces:
>>>>>> ======================================================
>>>>>> BinaryOperator 0x476f540 '_Bool' '<'
>>>>>> |-ImplicitCastExpr 0x476f528 'int' <LValueToRValue>
>>>>>> | `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'
>>>>>> `-IntegerLiteral 0x476f508 'int' 10
>>>>>> BinaryOperator 0x476f540 '_Bool' '<'
>>>>>> |-ImplicitCastExpr 0x476f528 'int' <LValueToRValue>
>>>>>> | `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'
>>>>>> `-IntegerLiteral 0x476f508 'int' 10
>>>>>> BinaryOperator 0x476f540 '_Bool' '<'
>>>>>> |-ImplicitCastExpr 0x476f528 'int' <LValueToRValue>
>>>>>> | `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'
>>>>>> `-IntegerLiteral 0x476f508 'int' 10
>>>>>> BinaryOperator 0x476f540 '_Bool' '<'
>>>>>> |-ImplicitCastExpr 0x476f528 'int' <LValueToRValue>
>>>>>> | `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'
>>>>>> `-IntegerLiteral 0x476f508 'int' 10
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Tareq A. Siraj 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> cfe-dev mailing list
>>>>>> cfe-dev at cs.uiuc.edu
>>>>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130626/f27fc62b/attachment.html>