Splint - Secure Programming Lint
info@splint.org
Manual Contents - Other Formats Section: 1  2  3  4  5  6  7  8  9  10  11  12  13  14  A  B  C  D  E     Sponsors - Credits

13        Completeness

Splint can report warnings for unused declarations and exported declarations that are not used externally.

13.1       Unused Declarations

Splint detects constants, functions, parameters, variables, types, enumerator members, and structure or union fields that are declared but never used.  The flags constuse, fcnuse, paramuse, varuse, typeuse, enummemuse and fielduse control whether unused declaration errors are reported for each kind of declaration.  Errors for exported declarations are reported only if topuse is on (see Section 13.2).

 

The /*@unused@*/ annotation can be used before a declaration to indicate that the item declared need not be used.  Unused declaration errors are not reported for identifiers declared with unused .

13.2       Complete Programs

Splint can be used on both complete and partial programs.  When checking complete programs, additional checks can be done to ensure that every identifier declared by the program is defined and used, and that functions that do not need to be exported are declared static.

 

Splint checks that all declared variables and functions are defined (controlled by compdef ).  Declarations of functions and variables that are defined in an external library, may be preceded by /*@external@*/ to suppress undefined declaration errors.

 

Splint reports external declarations that are unused (controlled by topuse).  Which declarations are reported also depends on the declaration use flags (Section 13.1).  The +partial flag sets flags for checking a partial system.  Top-level unused declarations, undefined declarations, and unnecessary external names are not reported if +partial is set.

13.2.1    Unnecessarily External Names

Splint can report variables and functions that are declared with global scope (i.e., without using static), that are not used outside the file in which they are defined.  In a stand-alone system, these identifiers should usually be declared using static to limit their scope.  If the export-static flag is on, Splint will report declarations that could have file scope.  It should only be used when all relevant source files are listed on the Splint command line; otherwise, variables and functions may be incorrectly identified as only used in the file scope since Splint did not process the other file in which they are used.

13.2.2    Declarations Missing from Headers

A common practice in C programming styles, is that every function or variable exported by M .c is declared in M .h.  If the export-header flag is on, Splint will report exported declarations in M .c that are not declared in M.h.

Next: 14. Libraries and Header File Inclusion
Return to Contents

Splint Manual
info@splint.org
1. Operation - 2. Null Dereferences - 3. Undefined Values - 4. Types - 5. Memory Management - 6. Sharing
7. Function Interfaces - 8. Control Flow - 9. Buffer Sizes - 10. Extensible Checking - 11. Macros
12. Naming Conventions - 13. Completeness - 14. Libraries and Header File Inclusion
Appendices: A. Availability - B. Flags - C. Annotations - D. Specifications - E. Annotated Bibliography - Index