An introduction to static code analysis

What, why and how

Internet Security Threat Report 2014

So, by some misfortune, usually instigated by "management" or by "tradition", you are stuck with a C/C++ program to maintain. Not only do you get the positives of speed, you also get the negatives of the lack of memory management.

How do you know what is lurking underneath the templates and calls to new and malloc? How do you know if that program is leaking memory or doing other dangerous things? In the past, you didn't. You could only scan the lines looking for errors or use tools like clint or valgrind.

Now, however, there are software tools that can help you to catch these kinds of errors before running the program. These tools are based on a technology called static code analysis and in this series, we will explore what this technology is, what tools are available, and what are its latest and future trends.

To illustrate the remarkable power of static code analysis we will use examples involving memory management and the use of pointer constructs in C/C++ since these are arguably one of the most error prone and hard to debug features in wide-spread programming languages. At this point, some might suggest that "no one writes in C/C++ anymore".

While garbage collected languages have become a large part of the programming marketplace, interestingly, C/C++ is still largely used in many critical domains: banking, embedded (automobiles), avionics, networking, operating systems, etc. Even when using a garbage collected language, they are often based on a Virtual Machine written in C/C++ which may itself have memory leaks or other errors.

Thanks to static analysis you can now automatically find those pesky mistakes (you know that your code is always perfect, right?). How does it work? First, a static analysis tool is a program which parses then analyses you source code. This means that in your toolchain the static analyser is an additional compiler. It does not produce binaries as such but produces an intermediate representation which is more suited than the source code to be analysed.

There are a variety of methods for analysis of your program: denotational semantics, axiomatic semantics, operational semantics, abstract interpretation, and separation logic. These rely on Formal Methods or complex mathematical/logical proofs against your code. We will cover these different methods in the next instalment. Suffice it to say now, one or more of these methods could be used to interrogate your code for different kinds of errors.

Depending on the methods used, as noted above, static analysis can take anywhere from a few minutes to much longer. Thus you must balance the time that analysis can take and the amount of time that you have available in your project. However, it is always a good idea to have one last run before sending code into production, no matter how long that might take.

An example will illustrate this process. Suppose you have a program like so:

#include <stdlib.h>

int *example1();
void alloc0(int **, int);

int main(int argc, char **argv) {

  return EXIT_SUCCESS;

int *example1() {
  int *i;

  alloc0(&i, 0); // ok
  alloc0(&i, 1); // ok, malloc 
  alloc0(&i, 1); // leak: i overwritten
  return i;

void alloc0(int **i, int b) {
  if (b) *i = malloc(sizeof (int));
  else *i = 0;

As you can see in the foregoing contrived example, there is an error in the example1() function which has to do with pointer manipulation. Essentially, i is overwritten without first freeing the memory allocated in the second call to alloc0().

This kind of bug is easy to miss and can cause massive problems in long running programs or in programs which are critical to your infrastructure. What a static analyser will do with your code is attempt to find some of the errors like the one above before you run the code (bug catching), therefore avoiding the bug when your client is using your software.

However, this is not the end of the story. Catching some bugs is typical of static analysers based on static code analysis 1.0. Researchers in the field have recently introduced a new capability which they believe will revolutionise the static code analysis arena: the ability to prove the absence of bugs.

This represents a dramatic leap forward in the technology, and some experts in the field have already named this as static analysis 2.0 (using the metaphor of Web 2.0 vs Web 1.0). To appreciate the difference, an analyser from the static analysis 2.0 category is effectively a "bug eradicator" able to eliminate all the bugs and showing an evidence that the code has been depurated. On the contrary, tools in the static analysis 1.0 category would be only able to find some existing bugs.

As you can see, knowing where subtle bugs like memory leaks and other pointer errors are is extremely valuable. Static analysis of your C/C++ code helps removing some of the most troublesome errors imaginable. It also takes away from the tedium of having to look at sometimes quite subtle errors such as memory allocation errors. In the next part of our series, we will show some of the maths behind the scenes.

Copyright © 2011 Christopher Yocum / monoidics

Chris is a Static Code Wrangler at monoidics.com

Security for virtualized datacentres

More from The Register

next story
Microsoft WINDOWS 10: Seven ATE Nine. Or Eight did really
Windows NEIN skipped, tech preview due out on Wednesday
Business is back, baby! Hasta la VISTA, Win 8... Oh, yeah, Windows 9
Forget touchscreen millennials, Microsoft goes for mouse crowd
Apple: SO sorry for the iOS 8.0.1 UPDATE BUNGLE HORROR
Apple kills 'upgrade'. Hey, Microsoft. You sure you want to be like these guys?
ARM gives Internet of Things a piece of its mind – the Cortex-M7
32-bit core packs some DSP for VIP IoT CPU LOL
Microsoft on the Threshold of a new name for Windows next week
Rebranded OS reportedly set to be flung open by Redmond
Lotus Notes inventor Ozzie invents app to talk to people on your phone
Imagine that. Startup floats with voice collab app for Win iPhone
'Google is NOT the gatekeeper to the web, as some claim'
Plus: 'Pretty sure iOS 8.0.2 will just turn the iPhone into a fax machine'
prev story


Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
The next step in data security
With recent increased privacy concerns and computers becoming more powerful, the chance of hackers being able to crack smaller-sized RSA keys increases.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.