A tool to detect bugs in Java and C/C++/Objective-C code before it ships
fbinfer.com
fbinfer.com
[1] https://github.com/facebook/infer/commit/9ec6cef8d1f48462919...
[2] http://docs.oasis-open.org/sarif/sarif/v2.0/csprd01/sarif-v2...
[3] https://docs.github.com/en/code-security/code-scanning/integ...
It worked out of the box, because fbinfer can tap into the compile commands database that can easily be generated by CMake and other build tools.
The tool has nice output about its current progress, but even when running with many threads, its long translation and analysis durations made it somewhat impractical to use on a large project. I understand that later it can run with incremental changes, and can reuse some data from previous runs. In this case it probably may be better suited. But the first-time analysis of a large project is very time-consuming. I am not saying this is unique to fbinfer. Other static analyzers tend to have the same problem. To be fair, I haven't yet inspected the tool's various options, which can potentially speed up the analysis.
The initial report the tool created contained several findings. Mainly "potential" nullptr dereferences and a few "potential" data races. After manual inspection these all turned out to be false positives. However, the tool also found several dead stores, which turned out to be actual dead stores. So it is at least helpful w.r.t.
From my perspective, the tool has potential. Probably some of the false positives can be turned off via configuration, and using it for incremental analysis may also reduce its runtime so that it becomes tolerable for larger projects.
https://lwn.net/Articles/869880/ https://gcc.gnu.org/onlinedocs/gccint/Static-Analyzer.html https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer https://developers.redhat.com/blog/2021/01/28/static-analysi... https://clang-analyzer.llvm.org/scan-build.html
Regarding gcc/g++, there seems to be support only for C. From https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer:
> Initial implementation was added in GCC 10; major rewrite occurred in GCC 11. > Only C is currently supported (I hope to support C++ in GCC 13, but it is out-of-scope for GCC 12)
Looking forward to seeing C++ support added to it!
Oh, I understand. There are two kinds of engineers: the lumpers and the dividers. The lumpers like to build one single massive engine that does everything, and the dividers prefer many small engines that do one thing, do it very well, and can be composed with other small engines in new and innovative ways and provide redundancy, maintainability, and scalability.
Obviously I count myself in the latter group. So the question for me is, what possible advantage would consolidating everything into one tool give me? Consider that I'm a software development toolchain engineer by trade in your reply.
I don't care whether under the hood the implementation is fully part of one big "compiler" engine or not, in the same way I don't care that when I run 'gcc' it's really running a compiler, assembler and linker which are all self-contained programs -- I do care that when I say "build my code" in the usual way that that is when analysis happens.
"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. "
I say this fondly though as a recovering Divider who still appreciates the pioneering spirit of Dividers.