Feeds

An introduction to static code analysis

What, why and how

  • alert
  • submit to reddit

Reducing security risks from open source software

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) {
  example1();

  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

The Power of One eBook: Top reasons to choose HP BladeSystem

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
prev story

Whitepapers

Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.