http://www.splint.org/manual/html/sec1.html
Splint is a tool for statically checking C programs for security vulnerabilities and programming mistakes. Splint does many of the traditional lint checks including unused declarations, type inconsistencies, use before definition, unreachable code, ignored return values, execution paths with no return, likely infinite loops, and fall through cases. More powerful checks are made possible by additional information given in source code annotations. Annotations are stylized comments that document assumptions about functions, variables, parameters and types. In addition to the checks specifically enabled by annotations, many of the traditional lint checks are improved by exploiting this additional information.
As more effort is put into annotating programs, better checking results. A representational effort-benefit curve for using Splint is shown in Figure 1. Splint is designed to be flexible and allow programmers to select appropriate points on the effort-benefit curve for particular projects. As different checks are turned on and more information is given in code annotations the number of bugs that can be detected increases dramatically.
Problems detected by Splint include:
· Dereferencing a possibly null pointer (Section 2);
· Using possibly undefined storage or returning storage that is not properly defined (Section 3);
· Type mismatches, with greater precision and flexibility than provided by C compilers (Section 4.1–4.2);
· Violations of information hiding (Section 4.3);
· Memory management errors including uses of dangling references and memory leaks (Section 5);
· Dangerous aliasing (Section 6);
· Modifications and global variable uses that are inconsistent with specified interfaces (Section 7);
· Problematic control flow such as likely infinite loops (Section 8.3.1), fall through cases or incomplete switches (Section 8.3.2), and suspicious statements (Section 8.4);
· Buffer overflow vulnerabilities (Section 9);
· Dangerous macro implementations or invocations (Section 11); and
· Violations of customized naming conventions. (Section 12).
Figure 1. Typical Effort-Benefit Curve
Splint checking can be customized to select what classes of errors are reported using command line flags and stylized comments in the code. In addition, users can define new annotations and associated checks to extend Splint’s checking or to enforce application specific properties (Section 10).
About This Document
This document is a guide to using Splint. Section 1 explains how to run Splint, interpret messages and control checking. Sections 2–13 describe particular checks done by Splint. There are some minor dependencies between sections, but in general they can be read in any order. Section 14 covers issues involving libraries and header file inclusion important for running Splint on large systems.
This document does not describe technical details of the checking. For technical background and analysis of Splint’s effectiveness in practice, see the papers available at http://www.splint.org.