Category Archives: Software Development

Your Two Cents About What Went Wrong With Static Analysis

I’ve gotten a lot of interesting feedback on the What Went Wrong with Static Analysis? post. So many people had their ideas about what was working, what wasn’t, and how to address it, that I thought I’d give people a chance to give their two cents.

I’ve created a poll which some basic issues as listed in the post and in various comments on it. Feel free to vote – there is a place if you have something not already on the list. After it’s been up for a bit I’ll post some results and commentary as is applicable.


Dennis Ritchie… Father of C, UNIX, and Much, Much More

I just posted a brief note about Dennis Ritchie at the Parasoft Blog. You can read about this amazing man who helped create C and Unix. Our thanks to him.

Reprinted below:

Dennis Ritchie - The creator of Unix and C
Dennis Ritchie – The creator of Unix and C

Dennis Ritchie, co-creator of the C programming language and UNIX operating system, died this week (2011). Back in the early days of Parasoft, we used to refer to “C” as “K&R C” (for “Kernighan and Ritchie C”). In fact, like lots of other long-time C programmers, many Parasoft veterans still have the classic C Programming Language book sitting on their bookshelves today.

Although he’s hardly a household name, Ritchie has had a tremendous influence on the software development community. Where might we be today if we didn’t have the luxury of building on his foundations?
On the language side, consider all the languages that were derived from C. Without C, there’s no C++…without which there’s no Java, no C#, and no Objective C. An enourmous amount of the software that we use everyday was built on those languages.

And on the OS side, think of all the things that stemmed from UNIX. Without UNIX, there’s no Linux. No Mac OS X. No Solaris. And without Linux, where would the open source community be? Would we have Android? What would the mobile device market look like? The server market?

In many ways, his vision was eerily similar to that of Steve Jobs: have it do what you really need it to do… and no more. It’s the epitome of elegant engineering.

If you compare C to Java, one of the defining differences is that Java is a very rich language. It has a built-in library that will cover pretty much anything you can think of. C has none of this—but it’s fantastically fast. It takes a lot less code to do something in C than it does in Java, VB, C# and the like. That’s really why C is still so popular. It’s a great balance between being close to the computer (and thus efficient) and being human understandable. The newer languages are more human understandable, but the trade off is that they’re rather inefficient compared to C.

The UNIX kernel is the same way. Amazingly, Thompson and Ritchie’s UNIX kernel was only 64K—smaller than the current Linux keyboard driver! UNIX truly respects the concept of having layers in an operating system. At the core, there’s just a kernel that runs the computer. Services lay on top of that. Networking is separate. Hard drives are an add-on (not core to the OS). And the GUI is a very high-level layer. This separation enables extreme efficiency. For example, while moving Windows to a new chip tends to open a can of worms, it’s actually quite simple with UNIX.

A few remarkable quips from Ritchie:

“I am not now, nor have I ever been, a member of the demigodic party.”

“UNIX is very simple, it just needs a genius to understand its simplicity.”

“C is quirky, flawed, and an enormous success.”

As Jon “Maddog” Hall, executive director of Linux International, tweeted: “…all programmers owe him a moment of silence.”

For a nice tribute to Ritchie, see the special Dr. Dobb’s newsletter.

What is Static Analysis… and What is it Good For?

As I talk to people about static analysis, I get a lot of questions and it seems that static analysis means different things to different people. The definitions people use for static analysis can be any or all of the things in this list:

  • Peer Review / Manual Code Review / Code Inspection
  • Pattern-based code scanners
  • Flow-based code scanners
  • Metrics-based code scanners
  • Compiler / build output

A working definition of static code analysis is the analysis of computer software that is performed without actually executing the software being tested. I’d like to talk briefly about each of these techniques, when/where to use it, and why it’s helpful.

Perhaps the oldest version of static analysis is Metrics-based code scanners where we look at things like complexity or even simply number of lines or methods in a file. Pattern based code scanners are what some think of as the traditional static analysis technique. A more modern offshoot of this is Flow-based code scanners where they look at paths through the code and say “Oh this could happen to you or that could happen to you”. The last is, which most people don’t think about, it output from your compiler or your build process which is a very valuable thing.

Peer Code Review

Let’s start with what we would call peer code review or code review or manual code review or code inspection. The idea is that humans are looking over each other’s shoulders, the idea being to check to see if the code is doing what you are trying to do. And there’s some really cool stuff out there to help you do this more efficiently. What you don’t want code review to be is checking syntax, or in fact anything that could be checked by an automated tool.

What we want to do is in some point, get some other eyeballs into some other’s code beyond the people who write for themselves, so we don’t get some kind of self-sustained mechanism that someone decides to do something in certain way.

Peer Code Review will help you finding problems early and functional problems. Most important part of Peer Code Review is have an access to mentoring process where other people look over your shoulder and can give you feedback like “you know… I would do that differently for this case. Here is better way to do it”.

You learn from code review because you benefit from the experience of others. In addition it helps you learn the code base because you are looking at other pieces of an application rather than just your own.

Pattern based analysis

Pattern based static analysis is finding a specific pattern from your code. This could be a good pattern meaning something you want in you code, or a bad pattern meaning something you don’t want to be in your code (bugs).

For example, I may have a branding issue. I want to make sure when my code prints out copyright statement. In this case the pattern is that certain code exists where I expect it to be, such as the footer of a web page.

Or the pattern might be a bad one, such as code that doesn’t free up resources when it’s done, causing memory leaks.

It may also be formatting issues that curly is here and under bar used there and case sensitive names used here and there. But we have to remember that it’s not just syntax problems but really things could cause a bug, for example when we try to internationalize our product or it may cause performance issue things like that.

Additionally the really cool thing about pattern based static analysis is that it improves the developers themselves. For example, a developer writes code for accessing a database. The code includes a try/catch block but he forgot to free up resources with a finally block.

The pattern based static analysis tool catches it and lets the developer know. After a few times with this warning, the developer will learn from it and start right code with a finally block to avoid the violation (and the nagging from the tool).

In other words, the tool is actually teaching the developer by suggesting a best practice  over and over again. Ideally, you encapsulate intelligence of your best developers into pattern based rules.

Pattern based static analysis is not just to check syntax and code formatting. It’s designed to save you time, not to “take time”. Some people say they don’t have enough time to perform static analysis, but generally, you don’t have enough time to skip it.

Flow Analysis

Flow analysis is the idea that instead of looking for a specific pattern in a particular file or class, we are going to look for a pattern based on trying to follow particular path through the application. But rather than run the application, it simulates the application execution.

Flow analysis looks possible paths of the logic and then manipulates the data to see if the bad pattern appears. For instance, it might try to inject bad data to see if it causes a problem, such as a SQL injection.

The paths are hypothetical in that they may or may not actually occur when you use the application, but they are at least possible. The cool thing is that it find real bugs in your application.

One of the things that flow analysis can find is uncaught exceptions. This may always be a problem because sometimes you handle the exception another way. For example, web application servers commonly have a wrapper to catch all exceptions. This is important because system uncaught exception acts basically same way as system exit.

Sometimes you have application stability issues, and very frequently it is related to unhandled exceptions. In such a case, flow analysis is a big help in improving your application.

API misuse is another common source of problems that are handled with flow analysis. Where the API not well understood or poorly documented it can lead to memory leaks or corruption.

With security, it finds the some potential types of problems for you that you can start to work on. It’s a great first pass, but it’s not as powerful as pattern based analysis for preventing issues and for giving thorough coverage, being limited to the hypothetical paths that the testing tool can figure out.


Metrics falls into two goals: you want to understand what’s going on in the code and the other is find possible problems. They do this by measuring something in the code. Sometimes when they people talk about metrics, they mean KLOC, cyclomatic complexity, number of methods or classes, things like that.

Metrics can point you to potentially dangerous design issue which is very helpful. They are generally more useful more at the design level than the debugging level.

When tools started doing static analysis about 20 years ago, there were a lot of metrics in place. When people had a bug in field and couldn’t reproduce it they tried to use metrics to suggest where the problem might be, then use a debugger to check the area suggested by the metrics.

The problem is that sometimes it gives you a good idea and sometimes it doesn’t. It really depends on what metrics you are looking for. If you’re using metrics to try and find bugs, it can be difficult and time-consuming. But if you’re trying to use them to understand your application, they actually end up telling you things.

So let’s assume you have a metric that measures the number of lines in files in your application and you start notice giant files. It probably means that design is not as good as it should be, because components should be very discrete and they should have known inputs and they should produce known outputs. When files get large they probably have a lot of complicated logic in the middle of them. Typically it is a good time to look at and refactor and build them down.

Compiler / build output

You should think of compiler warnings as a useful form of static analysis. Internally we set a policy many years ago that our products must compile without compiler warnings. It turns out that many of the compiler warnings are traceable to real problems in the field. At best, they mask real problems buried within your code. If you think that you can ignore compiler warnings, you’re assuming you know as much about the language as a compiler programmer. They put compiler warnings in place because they think about the code in terms of how the language is supposed to be used. If they give you a warning, it means they’re concerned that the code won’t operate properly. It’s best to pay attention to such warnings.

All of these types of static analysis can be valuable in improving your code and your development process, and even your developers as I discussed. I’ll go more in depth on these techniques in future posts.

As a reminder, I work for Parasoft, a company that among other things make static analysis tools. This is however my personal blog, and everything said here is my personal opinion and in no way the view or opinion of Parasoft or possibly anyone else at all.


Going with the Flow in Static Analysis

As part of my ongoing series about Static Analysis issues I want to talk about the relationship between the traditional static method and the newer dynamic or flow analysis method. People seem to misunderstand how the techniques relate and what each is good at. In particular, many seem to think that flow analysis is a replacement for non-dynamic analysis, which couldn’t be more wrong.

For the sake of having a simple term to identify both methods, I’ll refer to the older “static” method of static analysis and “pattern-based” and the newer flow-based method as “flow-based”. This is somewhat of a misnomer in that both types are really based on patterns, but seems to be a somewhat common way of referring to the two methods. If the terms I use bother you, feel free to do a search-replace function in your head when reading. I’m not too worried at this point about a strict technical explanation of each, but rather to their relationship. The goal is to have a way to differentiate in terms these two particular types of static analysis. Of course there are other types of static analysis as well, but I’ll leave that for another day.

Let me begin by saying that there is in fact a very strong relationship between pattern-based and flow-based static analysis, at least at an academic level. In almost every situation there are a set of pattern-based rules that would allow you to code in such a way that would prevent the occurrence of the issue being found by the flow-based rule. Given the nature of how flow analysis works, it can never find all possible paths through an application. This makes it a good idea to start programming in a more pro-active way to prevent the possibility of issues you’re concerned about.

For example, in security, one of the basic problems is using tainted data. Somewhere in the application between getting data from the user and operating on the data, you need to check if the data is safe. Depending on how far apart the operations are, it can be extremely difficult if not impossible to check every possible path. Security code scanners that rely on flow-based analysis attempt to find possible paths between user input and uses of the input that allow tainted data to be operated on. They can never find every possible path even if you let them run for an incredibly long time.

Instead, if you restructure your code so that input validation is done at the moment of input, then you don’t have any paths to chase, and you don’t have to worry about tainted data in your application. Flow-based tools won’t find anything anymore, because you won’t have any unprotected paths. This is sometimes a more difficult sell for developers, since it doesn’t provide them with a single broken piece of code that needs to be fixed. Rather it tells them that the way they’re writing code now could be improved – a bitter pill to swallow.

However applying this same principle to things like memory corruption, resource consumption, etc. can make the program far more robust than chasing possible paths ever could.

An excellent methodology is to start with flow-based analysis and fix the low-hanging fruit. Once you have compliance with your flow-based rule set, then review what you’re doing with flow and compare it to pattern-based static analysis. Determine as best you can how to apply static analysis and catch all possible potential problems before they happen, and put that into place. This moves you from a reacting to issues in your software to a more preventative stance.

There are those who say that flow-based analysis is preventative, but it’s still symptom driven – namely trying to find the openings and bugs you left in your code. Pattern-based analysis, when deployed properly, can be used to address the root problems. In our tainted data example, this means changing our coding style so that we don’t have paths where data could be tainted – root problem handled.

Essentially, flow-based analysis finds real bugs in possible paths. When you get a message from it, you just decide whether you care about that path or not. Static on the other hand tells you about the potential for a bug, not necessarily about the existence of a bug. Again, with our security example, Flow-based says “you used tainted data” where pattern-based says “this data could be tainted before use”.

When compared, you can see that flow-based analysis is a great way to find low-hanging fruit, because it’s looking for bugs instead of you doing it. On the other hand, because it works by guessing (flow fans hate the “guessing” term) at possible paths through your code, it will always be by it’s very nature incomplete.

Pattern-based analysis on the other hand requires restructuring your code and behavior if you want to achieve it’s full value. Some code is not well suited to such change, such as working legacy code.

Used together you have a very powerful solution that is much more robust than either technique on it’s own.

As a reminder, I work for Parasoft, a company that among other things make static analysis tools. This is however my personal blog, and everything said here is my personal opinion and in no way the view or opinion of Parasoft or possibly anyone else at all.