Errors in Fixed Format Code

| SimCon Home | fpt Reference Manual Home |

The Problems With Fixed Format Fortran Code

The most serious problem is that spaces between tokens are not required, and spaces within tokens are ignored. Small typographic errors can therefore result in statements which may look right but compile to something quite different from what was intended. This problem was made worse by the use of implicit typing. Variables did not need to be declared.

A second problem is that characters beyond column 72 in the code are ignored. This can trim the end of a variable name, silently changing the meaning of the code. Columns beyond column 72 are considered to contain comments, which are not required to be delimited.

There are other minor issues. One of the hardest to find are exclamation characters in the fixed-format continuation column, column 6. Compilers vary in their treatment of these. Sometimes they are treated as continuation characters, sometimes as comment delimiters. We have yet to see one cause a compilation error message.

Detecting Fixed Format Errors

fpt always reports:

Spaces within keywords, names or numbers (Except those in keywords such as "GO TO" and before the exponent character in numbers).
Missing spaces between keywords and names.
Code running past column 72 (Unless long source lines have been specified).
Exclamation characters in column 6.

It is important to check fixed format legacy code for errors before converting it to free format. A simple conversion tool may make the same interpretations as a compiler, and may hide anomalies from further analysis. Note that fpt will make the conversion to free format, and will report the anomalies as it does so.

As a warning against legacy fixed format, the code which probably destroyed Mariner I in 1961 is shown below. The error is the line DO 5 K = 1. 3. This should read DO 5 K = 1, 3. As written it means DO5K = 1.3. It should introduce a DO loop.