A mild introduction to static analyzers for C

16 Sep 2023

One in every of the beauty of C are the numerous pretty mature instruments within the ecosystem.
The unhealthy information nevertheless is that almost all academic supplies do not educate them and thus many
newcomers (and generally even skilled) builders have completely no consciousness
that these instruments even exists.

Right this moment I might wish to deal with this a tad bit by specializing in static-analyzers.
Static analyzers are instruments that may analyze your supply code and report potential bugs
with out having to run the supply code (therefore the “static” within the title).

Since that is alleged to be a delicate introduction (primarily aimed toward newcomers) I will be
specializing in static analyzers with the next properties:

• Simply accessible.
• Zero (or close to zero) setup.
• Concentrate on producing least quantity of false-positives (FP).

Compiler warnings

Earlier than going into extra specialised static-analyzers, it is worthwhile to speak a bit
about compiler warnings.
Whereas compiler warnings are in all probability essentially the most used type of static evaluation, it is nonetheless
criminally underused by newcomers.

A variety of static-analyzers additionally count on that you have already got compiler warnings turned
on and thus don’t try to catch errors that compilers already can catch.
So it is vital to arrange some respectable warning flags on your compiler.

For GCC and clang:

• -Wall activates a gaggle of warnings that may catch frequent errors.
• -Wpedantic can warn about sure non-portable extension utilization.
  That is helpful so you do not unknowingly find yourself introducing compiler
  extensions.
  Nevertheless remember that -Wpedantic is not a conformance checker, simply
  as a result of it does not warn doesn’t suggest the code is absolutely commonplace compliant.

The above flags alone virtually at all times will find yourself catching a bug or two (usually extra)
on a newbie’s code.
Nevertheless regardless of having “all” within the title, -Wall does not really flip all
warnings.
So a 3rd flag -Wextra can be helpful, which activates some extra (and someday
noisy) warnings.

You may additionally need to selectively disable some noisy warnings by utilizing
-Wno-${warning_name}, e.g -Wno-pointer-sign will disable -Wpointer-sign
warnings.
Nevertheless, it is best to at all times pay attention to what a warning is attempting to stop and why
that warning exists earlier than disabling it.

A pair different flags price mentioning:

• -Wshadow warns about when a variable shadows an outer one.
  This is not technically a bug, however unintended shadowing typically results in bugs so this
  finally ends up being an honest flags to make use of.
• -Wstrict-prototypes warns about out of date perform prototypes with
  unspecified amount of arguments.
• -Wvla to catch utilization of variable-length-arrays, that are non-portable and sometimes
  used with out warning.

Additional studying: “My favorite C compiler flags during development”
(additionally consists of recommendation on msvc).

And with some primary compiler flags out of the way in which, let us take a look at some extra specialised
static-analyzers.

A small caveat about GCC: for historic causes, GCC’s optimization and warnings are
tied collectively.
In different phrases, there are particular warnings (e.g -Wnull-dereference) that are solely
energetic when sure optimizations are energetic as nicely.
So that you’d need to additionally allow -O2 or above.

Cppcheck

Do not let the title idiot you.
Regardless of the title, cppcheck is completely able to analyzing C code.
It has a give attention to attempting to supply the least quantity of false-positives by default so
you may simply run it on a code-base with virtually zero-setup:

$ cppcheck -j$(nproc) --enable=portability src/*.c

The -j flag allows a number of thread, which might velocity up the method.
And the “portability” flag allows some fascinating portability warnings that different
static-analyzers typically miss.

You may also get a bit extra “strict” (learn: extra noisy) evaluation utilizing the next:

$ cppcheck -j$(nproc) --enable=type src/*.c

The type group allows all of the warnings from portability, efficiency and
warnings group, but in addition allows some stylistic warnings too (i.e decreasing variable
scope when doable and so on).

You’ll be able to selectively disable a examine utilizing the --suppress flag.
A pair different flags which are price mentioning are: --std to specify an ordinary,
-q to make cppcheck quiet, --inline-suppr so as to add assist for inline suppression
by way of feedback and you can too use -D and -U to outline and undefine macros comparable
to the -D and -U compiler (technically pre-processor) flags.

GCC’s fanalyzer

With newer a GCC model, you will have a further static analyze which will be
enabled as merely as appending -fanalyzer to your compiler flags.
I like to recommend utilizing at the very least GCC v12, since in my expertise there have been an honest quantity
of FPs in older variations.

Whereas GCC’s analyzer is not as mature as another choices, the course looks
promising.
And the truth that it requires principally zero-setup makes it much more interesting.

Disabling sure checks is similar as disabling warnings, -Wno-${check_name}.

The identical caveat about GCC’s optimization move nonetheless applies to -fanalyzer as nicely.

Clang-tidy

I have been hesitant about whether or not to place clang-tidy on this record or not.
On one hand, it is pretty highly effective.
However, it is default record of checks include a pair rubbish checks and
setting it up requires some effort in comparison with cppcheck or gcc’s -fanalyzer.

However finally I made a decision to incorporate it within the record since I feel the hassle is
worthwhile as a result of clang-tidy has caught various bugs in actual world program in my
expertise.

The very very first thing that you must do is disable the “insecureAPI” examine that is enabled
by default.
All it does is blindly flag commonplace capabilities as “unsafe” and advocate
non-portable and dubious annex Ok variants.
It’s totally disappointing that such low effort checks are enabled by default.
It does not catch precise bugs and steers amateurs who do not know any higher into
writing non-portable code with a false sense of safety.

Checks will be disabled on the command line by way of --checks or extra conveniently by means of
making a .clang-tidy config file.
If a examine begins with - it is disabled, in any other case it is enabled.
Globs are additionally supported, so -misc* disables all checks underneath misc class.

Here is a config which might function a very good “baseline”:

Checks: >
    performance-*,
    misc-*,
    android-cloexec-*,
    readability-duplicate-include,
    readability-misleading-indentation,
    bugprone-assert-side-effect,
    bugprone-macro-repeated-side-effects,
    bugprone-infinite-loop,
    bugprone-macro-parentheses,
    bugprone-posix-return,
    bugprone-reserved-identifier,
    bugprone-signal-handler,
    bugprone-signed-char-misuse,
    bugprone-sizeof-expression,
    bugprone-branch-clone,
    -clang-analyzer-security.insecureAPI.*,
    -misc-no-recursion,

# deal with all warnings as errors
WarningsAsErrors: '*'

CheckOptions:
  - key:             bugprone-assert-side-effect.AssertMacros
    worth:           'ASSERT'

ExtraArgs: [-std=c11,-DDEBUG]

It disables some annoying checks and allows a pair helpful ones.
Couple notable issues:

• The “insecureAPI” checks are thought-about dangerous and thus disabled.
• The android-cloexec class of checks recommends including O_CLOEXEC or equal
  flags when opening a fd. Nevertheless, a few of the suggestions usually are not a part of POSIX
  and thus will not be transportable. Be at liberty to disable this examine.
• Sure checks might settle for “choices”. For instance, I am utilizing it to inform clang-tidy
  about my customized ASSERT macro.

You’ll find the record of checks together with some description of what they do in
here.

In spite of everything this setup, you’d suppose it’d now be simple to get going by simply doing:

$ clang-tidy src/*.c

Virtually… The issue is clang-tidy requires you to move in varied
compiler/pre-processor flags in an effort to perform correctly.
So that you principally have to duplicate any compiler flags when invoking clang-tidy after
--:

$ clang-tidy src/*.c -- ${CFLAGS} ${CPPFLAGS}

You’ll be able to prepare your construct system to append these flags.
Or manually add them to ExtraArgs in your clang-tidy config.
Or there’s additionally a device referred to as scan-build which is an try at automating the
course of.

Lastly, particular warnings will be silenced by way of NOLINT feedback.
This may be helpful if you wish to silence a particular false-positive however do not need to
disable that examine totally.

Having the best mindset

Whereas the above instruments do a very good job at static evaluation, it is also vital to have a
proper mindset about it.
It is simple fall into the lure of aggressively enabling a shitload of noisy checks and
fooling your self into considering you are being productive by “fixing” them – when in
actuality you would possibly simply be doing busywork.

I’ve accomplished this early on as nicely.
In hindsight I can not precisely say it was a mistake since I did find yourself studying about
some really helpful flags which are not enabled by default within the course of.
However these days I’ve a way more strict criterion about whether or not or to not hold a
checks.

• Noise: How a lot false-positives does it produce?
• Efficient: Has the examine caught any actual bugs prior to now or does it appear prefer it
  would catch actual bugs sooner or later?
• Friction: How simple is it to silence the false-positives?

If a examine is not efficient and produces false-positives, then it is often not
price enabling.
If it is efficient however produces an excessive amount of noise or friction then I
may have it disabled by default, however from time to time I will allow it and see
if it finds any precise bugs (and ignore the false-positives slightly than performing some
dance to silence it).

The “proper” quantity of utility to friction ratio will clearly rely upon the challenge
(e.g one thing safety delicate operating as root vs some toy cat implementation).
However as a normal baseline, I’ve discovered that the above mindset provides a pleasant candy spot
the place you may get essentially the most quantity of utility out of static-analyzers whereas including the
least quantity of friction to your workflow.