splint
Analyze C code for errors
SYNOPSIS
splint [options] [files...]
PARAMETERS
-I directory
Adds directory to the list of directories to be searched for include files.
-D macro[=value]
Defines a preprocessor macro, optionally with a specific value.
-U macro
Undefines a preprocessor macro.
-config file
Loads configuration settings from the specified file.
-strict
Enables a stricter set of checks, suitable for high-assurance code, covering many common vulnerabilities.
-weak
Disables many checks, useful for quickly analyzing less critical or legacy code.
-nullwarn
Reports potential null pointer dereferences.
-uninit
Detects uses of uninitialized storage locations.
-retvalother
Warns if a non-void function's return value is ignored.
-paramuse
Reports function parameters that are declared but never used.
-unreachable
Identifies and reports unreachable code segments.
-fullprint
Causes error messages to print full pathnames of files.
-stats
Prints statistics about the analysis run, including the number of warnings and lines analyzed.
-warn option
Controls specific warning classes (e.g., -warn -null to disable null warnings). Can be used multiple times.
-help
Displays a summary of command-line options and configuration flags.
DESCRIPTION
Splint, short for Secure Programming Lint and formerly known as LCLint, is a robust static analysis tool designed to help developers identify a wide range of potential errors and security vulnerabilities in C programs. It works by analyzing source code without actually executing it, checking for common programming mistakes such as type inconsistencies, memory management errors (e.g., null pointer dereferences, memory leaks), uninitialized variables, dangerous use of library functions, and format string vulnerabilities.
Splint's effectiveness is significantly enhanced by the use of annotations embedded within the C code, which provide additional information about function contracts, data properties, and variable constraints, allowing for more precise and powerful checks. It offers extensive configurability through command-line options, enabling users to tailor the level of detail and types of checks performed, making it a valuable tool for improving code quality, reliability, and security during the development process.
CAVEATS
While powerful, Splint can sometimes produce false positives, requiring manual review of reported issues. Its maximum effectiveness is achieved when source code is properly annotated, which can add an initial development overhead, especially for legacy projects. Splint is primarily designed for C programs and does not fully support C++. It's also important to note that its development and maintenance have been less active in recent years compared to some other modern static analysis tools.
ANNOTATION SYSTEM
A key feature of Splint is its extensive annotation system. Developers can add special comments or types to their C code to provide Splint with more detailed information about function behaviors, variable properties, memory ownership, and other constraints. These annotations, such as /*@null@*/ or /*@owned@*/, allow Splint to perform much more sophisticated and precise checks, reducing false positives and identifying more subtle bugs that would otherwise be missed.
CONFIGURATION FILES
Splint's behavior is highly configurable, not only via command-line options but also through configuration files. Users can create .splintrc files in their home directory, project directories, or system-wide, to define default options, suppress specific warnings, or set up custom checking rules. This allows for consistent analysis settings across a project or organization without needing to specify all options on the command line every time.
HISTORY
Splint was originally developed by David Evans at the University of Virginia, first released as LCLint (Lint for Checking Properties of C Programs) in 1999. It was later renamed to Secure Programming Lint, or Splint, around 2000, reflecting its strong focus on identifying security vulnerabilities in C code. As an open-source project, it gained popularity in academic research and certain industry sectors for its rigorous static analysis capabilities. While foundational in its approach, the project's active development has significantly slowed in recent years, though it continues to be available and used.
SEE ALSO
cppcheck(1), clang-tidy(1), flawfinder(1)