Static code analysis tools for linux and C

Static code analysis tools for linux and C

Static code analysis is the analysis of source code for software defects(bugs). An effective static analysis framework in any project would go a long way is reducing the software development cycle. It should be remembered that no static code analyzer would satisfy every project needs and some of the tools have to go a long way before showing few false positive. A false positive is an possible defect reported by a tool but in reality it isn't. If your tool is throwing many false positives the real bugs might get hidden among the numerous false one and bug detection would be cumbersome.

Static Code Analysis using pattern matching

We have used pattern matching to successfully enforce style and detect certain bugs.

For example bugs like the following can be easily caught

if (ptr != NULL);
memset(ptr, 0, ....);

Another simple check that would be to check if return values of functions are always checked. For example if the return value of foo() needs to be checked atleast the return value needs to be assigned to or compared to. A simple grep foo *.c | grep -v "=" should throw up a few warnings. Its crude and would need fine tuning to remove false positives and can be caught by the compiler etc.

And the scripts you develop doesn't necessary need to find bugs. But running the scripts over a period of time eventually catch the odd bug that might have slipped.

GCC

The gcc compiler is has certain warning options which can be used for detecting bugs. -Wall is usually enabled in the build options, but sometimes you can enable -Wextra to enable the extra warnings. Also its good to use -Werror to force fixing of warnings.

You could selectively enable warnings specified to your needs. For example -Wparam-unused to check for unused function parameters. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html has the list of options available or 'man gcc' would list the warning options for your version of gcc.

SPARSE

You can get sparse from http://www.kernel.org/pub/software/devel/sparse/dist/ . Sparse is integrated into the kernel build system. Actually any checker can be run during a kernel or a custom kernel module build. To invoke a checker run 'make C=1 CHECK= ' For example:

make C=1 CHECK=sparse

What happes is that first the checker is run for a source file before invoking gcc for the source file. The compilation options passed to the checker is the same as the ones passed to gcc

More on sparse can be found in your linux sources Documentation/sparse.txt

SMATCH

We have use smatch to some degree of success. The homepage for smatch is smatch.sourceforge.net. To get and work with smatch do the following

git clone git://repo.or.cz/smatch.git

cd smatch && make && make install

The steps to run the checker would be similar to how we run sparse but CHECK=" --full-path" . smatch should normally be installed in your home dir/bin. For additional documentation check the home page

Working with static code analysis tools would require time and patience. Initially you would encounter many false positives but over time as you fix issues they would reduce and critical bugs can be found without having to go through a code review or a QA cycle.

Smatch has been completely rewritten in C and now uses sparse as a C parser instead of gcc as a C parser. The new URL is http://repo.or.cz/w/smatch.git.

Here are the new instructions:

git clone git://repo.or.cz/smatch.git cd smatch make cd ~/your/code/ make clean make CHECK="~/path/to/smatch/smatch --full-path" \ CC=~/path/to/smatch/cgcc | tee warns.txt Except if you are using smatch against the kernel the command is: make CHECK="~/path/to/smatch/smatch -p=kernel" C=1 \ bzImage modules | tee warns.txt

2.3.37 and after: Please set "CONFIG_DYNAMIC_DEBUG=n". That feature uses declared label things that mess up Smatch's flow analysis.

If you are using smatch on a different project then the most important thing is to build the list of functions which don't return. Do the first build using the --info parameter and use smatch_scripts/gen_no_return_funcs.sh to create this list. Save the resulting file under smatch_data/(your project).no_return_funcs and use -p=(your project) for the next smatch run.

If you are using smatch to test wine then use "-p=wine" to turn on the wine specific checks.