12.1 Static Analysis

Team-Fly

The methodological approaches to testing can be divided into two categories: static testing and dynamic testing. In the first category are to be found code inspection, whereby the source code is carefully examined and inspected line by line for such problems as deviations from specifications (in our case these are the selected algorithms), errors in reasoning, inaccuracies with respect to the arrangement of code lines or the style guide, doubtful constructions, and the presence of unnecessary code sequences.

Code inspection is supported by the use of analytic tools, such as the well-known Unix lint tools, that largely automate this laborious task. Originally, one of the main applications of lint was to compensate for earlier existing deficits in C in consistency checking of parameters that were passed to functions in separately compiled modules. Meanwhile, there have appeared more convenient products than the classical lint, products that are capable of discovering an enormous bandwidth of potential problems in program code, represented only in small part by syntax errors that definitively prevent a compiler from effecting a translation of the code. A few examples of the problem domains that can be uncovered by static analysis are as follows:

syntax errors,
missing or inconsistent function prototypes,
inconsistencies in the passing of parameters to functions,
references to or joining of incompatible types,
use of uninitialized variables,
nonportable constructs,
unusual or implausible use of particular language constructs,
unreachable code sequences,

An imperative condition for stringent type-checking by automated tools is the use of function prototypes. With the help of prototypes an ISO-conforming C compiler is capable of checking, across all modules, the types of arguments passed to functions and detecting inconsistencies. Many compilers can also be set to analyze the source code, as they recognize many problems when the appropriate warning levels are turned on. The C/C++ compiler gcc of the GNU project of the Free Software Foundation, for example, possesses above-average analysis functions, which can be activated with the options -Wall -ansi and -pedantic.^[2]

For static testing in setting up the FLINT/C functions, in addition to tests being performed on a number of different compilers (see page 7), above all were employed the product PC-lint from Gimpel Software (version 7.5; see [Gimp]) and LCLint from MIT (version 2.4; see [Evan]).^[3]

PC-lint has proved itself to be a very useful tool for testing both C and C++ programs. It knows about approximately two thousand separate problems and uses mechanisms that in a limited way derive from the code the values loaded into automatic variables at run time and include this in the diagnosis. In this way many problems, such as exceeding the limits of vectors, that are usually, if at all, detected only at run time (which is to say during testing, it is to be hoped, and not afterwards) can be uncovered already during static analysis.

In addition to these tools, the freely obtainable LCLint has been adapted to run under Linux. LCLint distinguishes four modes (weak, standard, check, strict), each connected with certain presets, and which carry out tests of varying degrees of rigorousness. In addition to the typical lint functions, LCLint offers possibilities to test programs for the presence of particular specifications, which are inserted as specially formatted comments in the source code. In this way boundary conditions for the implementation of functions and their invocation can be formulated and their conformity to specifications checked, and there are additional possible semantic controls.

For programs not equipped with supplementary specifications the mode set with the option -weak is recommended as standard. However, according to the manual a special reward will be presented to the first person who can produce a "real program" that produces no errors with LCLint in -strict mode. As a precondition for using these two tools in a reasonable manner it proved to be useful in testing the FLINT/C functions to test precisely which options are used and to create corresponding profile files so as to configure the tools for individual use.

After extensive revisions of the FLINT/C code, at the end of the test phase neither of the two products produced any warnings that on close examination could be considered serious. With this goes the hope that we have come a long way in fulfilling the conditions set above for the quality of the FLINT/C functions.

^[2]The compiler is included in the various Linux distributions and can also be obtained from http://www.leo.org.

^[3]LCLint can be downloaded from the Internet. The home page of LCLint is to be found at http://www.sds.lcs.mit.edu/lclint/. By anonymous ftp one can download LCLint for Linux and Windows 9x/NT from ftp://sds.lcs.mit.edu/pub/lclint/.

Team-Fly