Common Features Of Static Analysis Tools
Most source code analyzers perform a full program analysis, finding bugs caused by complex interactions between pieces of code that may not even be in the same source file.

The analyzer determines potential execution paths through code, including paths into and across subroutine calls, and how the values of software objects could change across these paths. Based on this value analysis, the analyzer can detect anomalous coding constructs, most of which would normally compile without error or warning. The following is a list of some of the more common errors that an analyzer will detect:

* Potential NULL pointer dereferences
* Access beyond an allocated area (e.g. array or dynamically allocated buffer); otherwise known as buffer overflow
* Writes to potentially read-only memory
* Reads of potentially uninitialized objects
* Resource leaks (e.g. memory leaks and file descriptor leaks)
* Use of memory that has already been deallocated
* Out of scope memory usage (e.g. returning the address of an automatic variable from a subroutine)
* Failure to set a return value from a subroutine
* Buffer and array underflows

The analyzer often has knowledge about how many standard runtime library functions behave. For example it knows that subroutines like free should be passed pointers to memory allocated by subroutines like malloc. The analyzer uses this information to detect errors in code that calls or uses the result of a call to these functions.

Figure 3 - Web page flaw summary

Modern static analyzers are well known for their ability to reduce the number of false positives. A false positive is a potential defect identified by the analyzer that could not actually occur during program execution. If an analyzer generates too many false positives, it will become irrelevant because the output will be ignored by engineers.

However, since an analyzer is not able to understand complete program semantics, it is not possible to totally eliminate false positives. In some cases, a defect found by the analyzer may not result in a fatal program fault, but could point to a questionable construct that should be fixed to improve code clarity. A good example of this is a write to a variable that is never subsequently read.

A common output format of a static analysis tool is a set of web pages hosted by a web server. The web interface enables the user to browse high level summaries of the defects found by the analyzer (Figure 3 above) and then click on hyperlinks to investigate specific problems.

Within a specific problem display, the error is usually displayed in context with the surrounding code, making it easy to understand (Figure 4 below). Function names and other objects are hyperlinked for convenient browsing of the source code. Since the web pages are running under a web server, the results can easily be shared and browsed by any member of the development team.

Figure 4 - Context-sensitive display

Open Source Static Analysis. Current generation open source static analysis tools such as lint and splint suffer from high false positive rates, making them impractical for use on complex software projects. The human analysis time required to sift through the false positives often far outweighs the cost of more accurate commercial static analysis tools.