coder . cl

Static analysis is cool, you can find bugs without running your programs or without debugging your programs, doing source code analysis with automated tools that analyzes your code execution path, variables and behaviour doing a static interpretation of your code. The resulting reports of static analysis can guide you to construct better code and correct a wide variety of errors on early stages of your program development, including hardening tasks, creating better programs with early corrections. There are various tools that can check your C source code and make your C programming tasks easier to handle.

The sophistication of the analysis performed by tools varies from those that only consider the behaviour of individual statements and declarations, to those that include the complete source code of a program in their analysis. Uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the lint tool) to formal methods that mathematically prove properties about a given program (e.g., its behaviour matches that of its specification) [Static program analysis, Wikipedia].

I’ve created a very simple Python script that wraps the execution of various of those tools to analyze C source code, grouping the execution of splint static analyzer, TenDRA static checker and cppcheck static checker. Those tools will allow you to verify your C source code using static analysis, and will allow you to find bugs in your C source code finding patterns of well known programming errors. Along the time, with practice, you will not write the same errors twice, and if you use those tools, you will enhance your programming habits by doing better code, with the assistance of those tools, for example using uninitiated variables or unchecked variables will not be a problem for you.

The tool cppcheck do not requires configuration, you just need to run it using a small set of flags, usually cppcheck --enable style --enable information --enable unusedFunction, so you do not require to create a configuration file and those tests made by cppcheck are very lightweight. The TenDRA compile just checks for standard conformance, and common flags in TenDRA are like tchk -Xs -Yxpg4 -Yposix. Among those three tools, the most complex one is splint, since it is a guided static analyzer, which uses comments to guide the static analyzer on program analysis. It requires a configuration file, that is called .splintrc and should be placed in your $HOME directory. My .splintrc configuration file is as follows:

##
## .splintrc example file
##

+strict
+matchanyintegral
+trytorecover
+unixlib
-sysdirerrors
-syntax

-bugslimit 50
-sysdirs /usr:/usr/include:/usr/local/include:/usr/include/bits
-DHAVE_CONFIG=1
-DHAVE_CONFIG_H=1
-DNDEBUG=1
-I/usr/include
-I/usr/local/include
-I/opt/include
-I./include
-I../include
-I.
-I..

That is a very basic configuration, but is almost complete to allow you to check your C source code. You will find splint reporting errors that your compiler will not display, for example if you are using GCC and your compiler flags are strict, like -Wall -Wextra -Wshadow -pedantic -std=c99 or -Wall -Wextra -Wshadow -pedantic -std=c90, will not report the same errors than splint does. You will find splint as a very strict tool to check your source code, displaying well known bugs, but not all reports should be handled as real, you must think on those errors that really have a real significance.

You can find the bugbuster.py script that I’ve wrote to use all those tools in one command from Emacs, by running the Emacs compile command on its web page here, and the source code repository to contribute or download the script is located on github.com here. Enjoy enhancing your source code.