[PATCH] D12780: [analyzer] Add generateErrorNode() APIs to CheckerContext

Anna Zaks via cfe-commits cfe-commits at lists.llvm.org
Fri Sep 11 13:34:03 PDT 2015


zaks.anna added inline comments.

================
Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h:244
@@ +243,3 @@
+                                  const ProgramPointTag *Tag = nullptr) {
+    return generateSink(State, /*Pred=*/nullptr,
+                       (Tag ? Tag : Location.getTag()));
----------------
xazax.hun wrote:
> zaks.anna wrote:
> > Please, use a non-null Pred for clarity
> The following workflow is not supported by this API: a checker that generates multiple transition in the same callback (the generated nodes are added sequentially to the path), and one of the might be an error node.
> 
> This also applies to generateNonFatalErrorNode.
> 
> In case we would like to improve the documentation it might be useful to give some pointers to the users which when should an error node be considered as fatal.
 - We could introduce another API that requires a Pred node.
 - The workflow is supported right now by directly using addTransition API.

================
Comment at: lib/StaticAnalyzer/Checkers/FixedAddressChecker.cpp:53
@@ -52,3 +52,3 @@
 
-  if (ExplodedNode *N = C.addTransition()) {
+  if (ExplodedNode *N = C.generateNonFatalErrorNode()) {
     if (!BT)
----------------
jordan_rose wrote:
> zaks.anna wrote:
> > Can this ever fail? In some cases we just assume it won't in others we tests..
> > 
> > Maybe it only fails when we cache out?
> It does fail when we cache out, and I think we can still cache out if Pred has a different tag the second time around.
There some instances in this patch where we do not check if the returned node is null. We should be consistent. 


http://reviews.llvm.org/D12780





More information about the cfe-commits mailing list