[PATCH] D72705: [analyzer] Added new checker 'alpha.unix.ErrorReturn'.

Balázs Kéri via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Aug 10 08:22:31 PDT 2020


balazske marked 3 inline comments as done.
balazske added inline comments.


================
Comment at: clang/lib/StaticAnalyzer/Checkers/ErrorReturnChecker.cpp:63
+                                          const BinaryOperator *BinOp,
+                                          const llvm::APSInt *KnownValue,
+                                          QualType RetTy,
----------------
Szelethus wrote:
> This is the value we're checking //against//, I think the name `KnownValue` doesn't convey this.
Renamed to `ValueToTestAgainst`.


================
Comment at: clang/lib/StaticAnalyzer/Checkers/ErrorReturnChecker.cpp:79-80
+                                  bool ChildIsLHS) const override {
+    if (!KnownValue)
+      return false;
+
----------------
balazske wrote:
> Szelethus wrote:
> > So if we failed to get retrieve the value we're checking against, we automatically assume that its not a proper check? Shouldn't we be conservative here? What if that value is something like `getEOFValue()`?
> This case needs attention, now it is detected as failure (maybe the function can return `Optional<bool>` to indicate a non-determinable case).
This case is now not error.
A test is added for this case.
```
  int R = fputs("str", file());
  if (R == getEOFValue())
    return;
```
This is no warning now (but `getEOFValue` can return anything).


================
Comment at: clang/lib/StaticAnalyzer/Checkers/ErrorReturnChecker.cpp:83
+    bool KnownNull = KnownValue->isNullValue();
+    bool KnownEOF = ((*KnownValue) == BVF.getValue(-1, RetTy));
+
----------------
Szelethus wrote:
> We have a smarter EOF getter thanks to @martong, don't we?
`tryExpandAsInteger` is used now.


================
Comment at: clang/lib/StaticAnalyzer/Checkers/ErrorReturnChecker.cpp:220-223
+/// Information about a specific function call that has an error return code to
+/// check. This data is stored in a map and indexed by the SymbolRef that stands
+/// for the result of the function call.
+struct CalledFunctionData {
----------------
Szelethus wrote:
> The comments leave me to believe that the correct class name would be `FunctionCallData`, right? Because `FnInfo` does the job of describing the called function, and this one deals with the actual call.
`CalledFunctionData` was renamed to `FunctionCallData` and `CFD` variables to `Call`. It looks better now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72705/new/

https://reviews.llvm.org/D72705



More information about the cfe-commits mailing list