
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 25, 2013, at 10:28 AM, "Siraj, Tareq A" <<a href="mailto:tareq.a.siraj@intel.com">tareq.a.siraj@intel.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Anna,<br>Thanks for your reply. I am looking at existing bugzilla entries and picked up<span class="Apple-converted-space"> </span><a href="http://llvm.org/bugs/show_bug.cgi?id=5067">http://llvm.org/bugs/show_bug.cgi?id=5067</a>.<br><br>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.<br></div></blockquote><div dir="auto"><br></div><div dir="auto">You can just look for cases where you see the initialization of the iterators. That would be the majority of cases anyway.</div><div dir="auto"><br></div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Is it safe to cache the analyzed Stmt into a registered list so that we don't analyze the same Stmt 4 times? Thanks.<span class="Apple-converted-space"> </span><br></div></blockquote><div><br></div><div>The visited Stmt can be cached in the state.</div><div>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..</div><div><br></div>Anna.</div><div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>--<br>Tareq A. Siraj<span class="Apple-converted-space"> </span><br><br><br>On 2013-06-25, at 1:14 PM, Anna Zaks <<a href="mailto:ganna@apple.com">ganna@apple.com</a>><br>wrote:<br><br><blockquote type="cite">Siraj,<br><br>What you are seeing is expected - the analyzer processes entrance to the loop 4 times along the execution path.<span class="Apple-converted-space"> </span><br><br>What is the check you are trying to write? Is it path-sensitive in nature?<br><br>Cheers,<br>Anna.<br><br>On Jun 25, 2013, at 8:10 AM, "Siraj, Tareq A" <<a href="mailto:tareq.a.siraj@intel.com">tareq.a.siraj@intel.com</a>> wrote:<br><br><blockquote type="cite">Hello,<br>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,<br>(1) Is this a bug?<br>(2) Is check::BranchCondition the right checker to use here?<span class="Apple-converted-space"> </span><br><br>Thanks.<br><br>Sample for loop:<br>=============<br>for (int i = 0; i < 10; ++i)<br><br>Calling dump() on the statement in checkBranchCondition() produces:<br>======================================================<br>BinaryOperator 0x476f540 '_Bool' '<'<br>|-ImplicitCastExpr 0x476f528 'int' <LValueToRValue><br>| `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'<br>`-IntegerLiteral 0x476f508 'int' 10<br>BinaryOperator 0x476f540 '_Bool' '<'<br>|-ImplicitCastExpr 0x476f528 'int' <LValueToRValue><br>| `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'<br>`-IntegerLiteral 0x476f508 'int' 10<br>BinaryOperator 0x476f540 '_Bool' '<'<br>|-ImplicitCastExpr 0x476f528 'int' <LValueToRValue><br>| `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'<br>`-IntegerLiteral 0x476f508 'int' 10<br>BinaryOperator 0x476f540 '_Bool' '<'<br>|-ImplicitCastExpr 0x476f528 'int' <LValueToRValue><br>| `-DeclRefExpr 0x476f4e0 'int' lvalue Var 0x476f450 'i' 'int'<br>`-IntegerLiteral 0x476f508 'int' 10<br><br><br>--<br>Tareq A. Siraj<span class="Apple-converted-space"> </span><br><br><br><br><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</blockquote></blockquote></div></blockquote></div><br></body></html>