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 matchingWe 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.
GCCThe 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. has the list of options available or 'man gcc' would list the warning options for your version of gcc.
SPARSEYou 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=
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
SMATCHWe 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="
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 .
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.txt2.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.