[PATCH] D154423: [clang][analyzer] Add all success/failure messages to StdLibraryFunctionsChecker.

Fri Jul 7 06:09:04 PDT 2023

donat.nagy added a comment.

I looked through most of the open source results, and they look promising.

However I've seen one questionable tendency: there are many reports (e.g. this one <https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?run=postgres_REL_13_0_stdclf_notetag_interesting_test_3&is-unique=on&report-hash=757a1b54859b371e03a3067d2f7ed98a&report-filepath=%2apgbench.c&report-id=1935236>) where the checker assumes that `fileno(stdin)`, `fileno(stdout)` or `fileno(stderr)` fails. How realistic are these assumptions? Do we need to bother the programmer with these or should/can we silence them (and perhaps return the known fileno values corresponding to these standard streams)?

Another, concrete issue is this report <https://codechecker-demo.eastus.cloudapp.azure.com/Default/report-detail?run=xerces_v3.2.3_stdclf_notetag_interesting_test_3&is-unique=on&report-hash=ab9f0996ac95dd6c29d4b5f4f54b9636&report-filepath=%2aThreadTest.cpp&report-id=1943352> where the analyzer assumes that `ftell` returns `-1` (that gets converted to 2**64-1 because unsigned numbers are crazy), but there is no note tag (not even in the _3 run) and I don't see where does this assumption come from (although I didn't do a deep analysis).

Apart from these, the false positives are coming from general limitations of the engine that cannot be reasonably avoided.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154423