Fortran programs are used to design aircraft, ships, bridges, power plant,
space craft, medical drugs ... Perhaps most importantly, they are used to model the Earth's climate and to inform the
prediction of climate change. The engineers and scientists already know that the results they generate are about right.
Man years of program development on expensive equipment are invested for the last few percent
of accuracy which go beyond the engineer or scientist's intuition. The achievement of this last few percent depends on
the quality of the code.
Three aspects of code quality are handled by FPT.
Is the code well written? Is it well formatted, adequately commented, and are the variable names meaningful?
- FPT automatically handles code layout and formatting. Please see the reference manual pages on
- FPT measures the number of comments and, more importantly, the number of words in comments. These are reported by the
SHOW METRICS command.
- Non-local names should be sufficiently long to be meaningful. FPT measures the average length of the names used for objects visible in
multiple routines to provide a measure of meaningfulness.
- Names visible in many different routines should be unique so that they cannot be confused with local names. FPT measures the
proportion of the names used for non-local objects which are unique. Again, please see the Code Metrics page
and the SHOW METRICS command for further description.
Is the code fully tested? Do the tests exercise all of the code? Is the test suite well automated?
- FPT provides tools for test coverage analysis. The tests show the proportion of
the code exercised in a test, and facilities are provided to merge coverage data from different test runs.
- The record / replay facility may be used to create automated test suites, particularly where there are manual
inputs to a program, or where the program accesses a database.
- The run-time trace facility may also be used to automate testing, and may be used to eliminate numerical
drift from test runs where code is tested under different compilers or environments.
Are there errors? The issue of coding errors is described below.
Errors in Microsyntax, Syntax and Semantics
When FPT reads a program it carries out a detailed syntactic and semantic analysis in the same way as a Fortran compiler. Diagnostics are
reported, for example:
Most, but not all of these occurrences indicate problems. FPT supports nearly all of the language extensions used in different compilers
but there must be some which we have not yet encountered. We attempt to keep FPT up to date with the latest Fortran standard, but new
keywords and constructs are added every few years.
If FPT is unable to analyse all or part of the syntax of a statement.
If names are used inappropriately, for example, where a Fortran keyword is used to name a variable, or where the use of a name
conflicts with its declaration.
If expressions are constructed in such a way that there is a loss of precision.
If the actual arguments passed to sub-programs cannot have the INTENT required by the sub-program code - e.g. where a constant is
passed to a sub-program in an argument to which the sub-program writes a result.
These diagnostics are always issued unless they have been explicitly suppressed (See the SUPPRESS
Checks for Specific Classes of Error
Commands are available to check for specific classes of errors. Most of the checks may also be modified by filters which suppress reports
of the less serious cases. The checks are:
Sub-program Argument Check
FPT checks that the actual arguments passed to sub-programs are consistent with the formal arguments in
the sub-program declarations. The arguments must match in:
- data type, i.e. INTEGER, REAL, COMPLEX, CHARACTER, Derived TYPE etc.;
- data kind and size, e.g. REAL*4, REAL*8 etc.
- intent, whether input, output, input and output, sub-program argument etc.;
- protocol, whether passed by reference, value, address and length, descriptor etc.;
- array shape. The array shapes must conform though they need not match exactly.
Sub-program Argument INTENT Check
FPT checks that the INTENT (if any) declared for a sub-program argument is consistent with the way in which the argument is used.
If the same name is used for two or more objects in a program, FPT checks that the attributes of the objects are the same.
In particular, checks are made for variables with the same name at different COMMON block addresses, and for Fortran parameters
with the same names but different values in different routines. Note that these occurrences are not Fortran errors.
However, they may indicate coding errors.
A check is made for variables forced to mis-aligned addresses as a result of SEQUENCE DERIVED TYPE, COMMON block.
STRUCTURE/MAP/UNION or EQUIVALENCE constructs.
Checks are made for:
- Objects which are forced to the same COMMON block address without an explicit EQUIVALENCE statement.
- Objects of different data types or kinds which are set at the same address by EQUIVALENCE statements.
Check of DATA in COMMON
A check is made that each COMMON block is initialised by DATA statements in at most only one program unit. This command
detects a problem with the Linux, Unix and Windows default linkers. If a COMMON block is initialised in more than one
BLOCK DATA or other program unit, these linkers overwrite all of the initialisations by the last one linked. All of the other
initialisations are lost.
Data Type Coercion Check
Checks are made for the use of inappropriate data types in Fortran constructs. The most common to be encountered is the use
of an integer variable in a context which requires a logical. Many compilers do not report this as an error.
Array Bounds Check
A check is made that all array indices are within the bounds of the array. Two checks are made. If the index is a constant, it
is checked and an error is reported if it is out-of-bounds (Most compilers also make this check). If the index is a variable,
the relevant assignments of the variable are identified. If the variable is expected to go out-of-bounds a warning is issued.
Checks are made for variables which are, or may be:
- used before they are assigned;
- assigned values which are never used;
- declared but never used.
Whole Array Assignment Check
FPT checks for unsubscripted whole arrays which are assigned to scalar values across an equals sign. This is legal Fortran
(Fortran 90 and Gould-SEL Extended Fortran 77) but is a common source of error.
Program Flow Analysis
A check is made for unreachable code.
Ambiguous Flow Check
FPT checks for cases where the program flow is ambiguous. This occurs when a statement contains two or more function invocations
at equivalent levels of expression nesting. The Fortran standard explicitly states that the order of evaluation is undefined.
This may lead to inconsistent results, and it makes comparison of program behaviour under different compilers difficult.
Overloaded Assignment Check
Fortran 90 (and later) allows the assignment of variables of derived types to be overloaded and to be
carried out by user-defined subroutines. If no overload exists, the values of the types are copied directly. A problem
exists that an error in exporting or declaring the overload may prevent it from taking place. This command checks
that, where an overload exists, the assignment is always overloaded and is never made directly.
FPT attempts to infer the units and dimensions of real variables, and to detect inconsistent uses. Please note
that this command is experimental and forms part os a research project.
In auditing, the objective is to assess the state of a code, not to change it. It is recommended that a standard test regime is set up in
an fsp file with a chosen set of checks, and that this is applied to a number of projects to gain a comparative feel
for code quality. The procedure for setting up projects and fsp files is described in
"Running fpt" in the FPT Reference Manual. An example QA auditing file is described on the
If the intention is to enforce a QA regime and to remove errors, it is recommended that the project is set up in the same way
as a software migration. This is essentially a migration from the original sources to a corrected code base. Please see the description
of Migration in the FPT Reference Manual. We recommend setting up
parallel original_source, modified_source and fpt_output directory
structures as described there. FPT may then be used to reformat the code and to make some of the changes.
Copyright ©1995 to 2014 Software Validation Ltd. All rights reserved.