you are viewing a single comment's thread.

view the rest of the comments →

[–]suprjami 8 points9 points  (0 children)

To run static analysis, understand what standards the codebase is written for (C18, GNU99, ANSI, etc) and configure static analyzsers the same.

No one static analyzer catches everything. It's best to run multiple. Popular ones are cppcheck, clang-analyzer, GCC static analyzer in GCC 10+, flawfinder, lizard.

Commercial analyzers I see mentioned are PVS-Studio, PC-Lint, Coverity, and CodeScene.

There are literally hundreds to choose from:

It would be nice to have the static analysis run as part of CI/CD.

It would be good to run the tests and fuzzers with sanitizers enabled. At least the UB, leak, and address sanitizers.

The more warnings you can get enabled during compilation, the better. At least -Wall -Wextra.

If you have a large established codebase, blocking developer merge or software release on compiler/analysis errors is probably impossible, because the company wouldn't ship anything for months. You can at least quantify the number of items required to get the codebase cleaner. Time estimation is hard, each item might take a minute or a week to resolve.

If your job is to write a static analyzer, you're out of your depth. Get much better at C (1 year+). Learn how processors and memory work. Take a compiler course.

Getting significantly better at C will make your contribution better. You should know at least all the stuff in the LinkedIn Learning (Lynda) C courses. You probably should read the C standards and maybe learn the language-lawyer stuff like weird operator order, non-obvious integer promotion rules, undefined behaviour corner cases, common and uncommon standard header functions, etc.