The note tag that was previously added in all cases when a standard function call
is found is displayed now only if the function call (return value) is "interesting".
This results in less unneeded notes but some of the previously good notes disappear
too. This is because interestingness is not always set as it should be.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp | ||
---|---|---|
1336 | Why do you continue here? Do you have a case for this? |
Here are results for vim, still the fileno problem is not fixed. This run was made before the last update where markInteresting is added, then it should work.
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp | ||
---|---|---|
1336 | This is only because the same loop has other failure places (if the state can not be applied) where continue is used already. The reason is that if one addTransition fails a next one may succeed. It is probably better to use break at all places. Even then what was already added to the state can not be removed, so it may be not wrong to add all states that can be added. |
LGTM if you rebase these changes onto the most recent version of D153612. Thanks for adding this interestingness check!
results with the latest version: | |
memcached_1.6.8_stdclf_notetag_interesting_test_2 | Reports |
tmux_2.6_stdclf_notetag_interesting_test_2 | Reports |
curl_curl-7_66_0_stdclf_notetag_interesting_test_2 | Reports |
twin_v0.8.1_stdclf_notetag_interesting_test_2 | Reports |
vim_v8.2.1920_stdclf_notetag_interesting_test_2 | Reports |
openssl_openssl-3.0.0-alpha7_stdclf_notetag_interesting_test_2 | Reports |
sqlite_version-3.33.0_stdclf_notetag_interesting_test_2 | Reports |
ffmpeg_n4.3.1_stdclf_notetag_interesting_test_2 | Reports |
postgres_REL_13_0_stdclf_notetag_interesting_test_2 | Reports |
xerces_v3.2.3_stdclf_notetag_interesting_test_2 | Reports |
bitcoin_v0.20.1_stdclf_notetag_interesting_test_2 | Reports |
Thanks for attaching the test results! Unfortunately it seems that it was important to look at them, because I noticed that in the posgresql codebase there are many bug reports on calls like func1(func2(...), ...) where the checker does not print the expected "Assuming that 'func2' fails" note: fdopen/dup, fstat/fileno, isatty/fileno, another isatty/fileno, a third isatty/fileno, a second dup/fileno (this is not an exhaustive list, but I think I listed the majority of them).
Please investigate these before merging your commits.
The success/failure note tags are not added to all functions, dup is one of these, this means at dup no note tag is shown. A next patch can be made to add these messages to all functions. The other places look good, but CodeChecker is a bit tricky, you must select *_stdclf_notetag_interesting_test_2 at the small arrow after the "found in:" text (upper right corner). The link is good but not that instance of the bug is displayed because only the note tags are different.
I think we should definitely add success/failure note tags to all functions where this checker can suddenly assume that "Oops, this failed". If this "Assuming that 'foo' fails" message is not there, it's a very natural reaction to search for some earlier note that would let the checker deduce that this function will fail here.
Why do you continue here? Do you have a case for this?