[cfe-dev] avoid loops in the exploded graph?
Kristóf Umann via cfe-dev
cfe-dev at lists.llvm.org
Tue Oct 9 02:10:41 PDT 2018
Hi!
If you look at how addTransition is implemented, you can see a big TODO
before a defensive check:
https://github.com/llvm-mirror/clang/blob/7c8e954f273730037b454edf94c8d13123dbedf6/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h#L289
According to that, it would seem that a checker-side check should always be
there.
Let's see what others think of this -- to me it would make more sense to
have this check within addTransition, and I'm unsure myself why that TODO
is there.
Lou Wynn via cfe-dev <cfe-dev at lists.llvm.org> ezt írta (időpont: 2018. okt.
9., K, 3:42):
> Hi,
>
> I read the comment "avoid loops in the exploded graph" in the following
> snippet of code which is on page 32 of the workbook
> <https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf>
> .
>
> LocationContext *LC = C. getLocationContext ();
> ProgramStateRef State = C. getState ();
> const Expr *E = /* Obtain an expression value of which is untrusted */;
> ProgramStateRef NewState = State -> addTaint (E, LC );
> if ( NewState != State ) // avoid loops in the exploded graph
> C. addTransition ( NewState );
>
> My question is why the new tainted state requires the if statement to
> prevent loops, while other new states in the book do not have the if
> statement when C.addTransition(State) is used? Do other states which are
> not tainted not need to prevent loops? For example, on page 30, when a new
> state is added, it reads:
>
> ProgramStateRef State = C. getState ();
> State = modifyState ( State ); // do stuff
> C. addTransition ( State );
>
> There is no if state to prevent a loop.
>
> --
> Love,
> Lou
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181009/16d3957f/attachment.html>
More information about the cfe-dev
mailing list