[PATCH] D48027: [analyzer] Improve `CallDescription` to handle c++ method.

Gábor Horváth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 13 09:32:26 PDT 2018


xazax.hun added inline comments.


================
Comment at: lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp:32
                                                      check::PostCall> {
-  CallDescription CStrFn;
+  const llvm::SmallVector<CallDescription, 4> CStrFnFamily = {
+    {"std::basic_string<char>::c_str"}, {"std::basic_string<char32_t>::c_str"},
----------------
I am not sure if this is the right solution in case of this check. We should track `c_str` calls regardless of what the template parameter is, so supporting any instantiation of `basic_string` is desired. This might not be the case, however, for other checks. 

If we think it is more likely we do not care about the template arguments, maybe a separate API could be used, where we pass the qualified name of the class separately without the template arguments.
Alternatively, we could use matches name so the users could use regexps.

At this point I also wonder what isCalled API gives us compared to matchers? Maybe it is more convenient to use than calling a `match`. Also, isCalled API has an IdentifierInfo cached which could be used for relatively efficient checks.

@NoQ what do you think?




================
Comment at: lib/StaticAnalyzer/Checkers/DanglingInternalBufferChecker.cpp:65
   auto *TypeDecl = TypedR->getValueType()->getAsCXXRecordDecl();
   if (TypeDecl->getName() != "basic_string")
     return;
----------------
If we check for fully qualified names, this check might be redundant.


================
Comment at: lib/StaticAnalyzer/Core/CallEvent.cpp:273
+  auto Matches =
+      match(namedDecl(hasName(CD.FuncName)).bind("match_qualified_name"), *ND,
+            LCtx->getAnalysisDeclContext()->getASTContext());
----------------
Doesn't match also traverse the subtree of the AST? We only need to check if that particular node matches the qualified name. I wonder if we could, during the traversal, find another node that is a match unintentionally.


Repository:
  rC Clang

https://reviews.llvm.org/D48027





More information about the cfe-commits mailing list