Add a checker that checks if a function is used without examining
its return value. The set of functions is taken from CERT rule
ERR33-C "Detect and handle standard library errors". This is a
simplified check for the problem.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
400 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
This is a very simplified form of the check that is implemented in D72705 but still may be useful in practical cases. This check could be a clang-tidy check but it is planned that the checker takes use of the planned new attributes to determine if a function should be checked.
clang/lib/StaticAnalyzer/Checkers/UncheckedReturnValueChecker.cpp | ||
---|---|---|
42 | Please note that the CallExpr does not necessarily stands alone. It may be wrapped into an ExprWithCleanUps. We should consider these CallExprs as unchecked too. | |
86 | Hmm, why StringMap<>? Why not CallDescriptionMap<>? | |
clang/test/Analysis/unchecked-return-value.cpp | ||
11 | Please use some valid format here. E.g. scanf("%*c"); | |
17 | Please add such simple test case for all the functions we try to check. (One call is enough for every such function, either in std:: or on the top namespace.) |
Maybe it is better to have this check for every system function that has non-void return value (except specific functions)? This check is applicable to CERT rule ERR33-C, POS54-C and EXP12-C too (it is restricted but can find a part of the problems).
Looks like a neat checker! I guess the only question is the function matching, and I don't dislike it in its current state. @martong, do you have any thoughts on this?
On another note, have you checked this on some projects yet? I expect that we might need to tone down on some of the functions if this ends up being too noisy.
clang/lib/StaticAnalyzer/Checkers/UncheckedReturnValueChecker.cpp | ||
---|---|---|
66–67 | I suppose we need this to compensate for the fact that we can't reliably match on standard C functions. Unfortunately, using CallDescription wouldn't necessarily solve this: D81745. | |
86 | Good point. @martong, you have used FunctionDecl based checking, do you have any thoughts here? |
Great job!
I'd like to see more tests with the following cases:
- more expressions with function calls - ternary expression, arithmetic, array literals, initializer lists, etc.
- using/not using it in if statement with initializer
- using/not using it in different parts of GNU statement expressions
- calls in different parts of exception handling (both C++ and Obj-C)
- calls in lambdas/blocks/coroutines
- calls in different parts of C++ range-for loop
- calls in different parts of Obj-C for loop over collections
- calls under labels
- calls in attributed statements (e.g. [[clang::nomerge]] foo())
- calls in goto statements
- calls in Obj-C @synchronized and @autoreleasepool statements
but it is planned that the checker takes use of the planned new attributes to determine if a function should be checked
This is literally __attribute__((warn_unused_result)) for which there already is a compiler warning.
There is a clang-tidy check bugprone-unused-return-value that may be confusing in relation to this checker. It does similar job for a selected set of functions and with different reason.
clang-format not found in user's PATH; not linting file.