...
When
...
choosing
...
a
...
compiler
...
(which
...
should
...
be
...
understood
...
to
...
include
...
the
...
linker),
...
a
...
C99-compliant
...
compiler
...
should
...
be
...
used
...
whenever
...
possible.
...
When
...
choosing
...
a
...
source
...
code
...
analysis
...
tool,
...
it
...
is
...
clearly
...
desirable
...
that
...
the
...
tool
...
be
...
able
...
to
...
enforce
...
as
...
many
...
of
...
the
...
guidelines in
...
this
...
document
...
as
...
possible.
...
To
...
the
...
greatest
...
extent
...
possible,
...
the static analysis tool should be both complete and sound.
A static analysis tool is considered sound (with respect to a specific guideline) if it does not give a false-negative result, meaning it is able to find all violations of a guideline.
A static analysis tool is considered complete if it does not issue false-positive results, or false alarms. Too many such false alarms rapidly lead users to ignore the results of a tool, potentially missing serious issues.
The possibilities for a given guideline are outlined in the table below. The tool may report defects which don't exist (false positives), or may fail to report defects which do exist (false negatives).
These lead to the following possibilities for a given guideline:
- Fully implemented (sound and complete)
- Complete with false positives
- Incomplete
- Incomplete with false positives
- Not implemented
- Not applicable
Compilers and source code analysis tools are trusted processes, meaning that a degree of reliance is placed on the output of the tools. Consequently, developers must ensure that this trust is not misplaced. Ideally, this should be achieved by the tool supplier running appropriate validation tests. While it is possible to use a validation suite to test a compiler or source code analysis tools, no formal validation scheme exists at this time.