I have been writing a small static analyser for legacy Fortran and it has
reached the point where it might be useful to other people.
It looks for the constructs that change results rather than merely offend
taste: code silently truncated past column 72, initialised locals carrying an
implicit SAVE, EQUIVALENCE aliasing, missing IMPLICIT NONE, assumed-size
dummies, arithmetic IF. Twenty-one rules. It prints a terminal summary or a
self-contained HTML report.
Zero dependencies, pure Python standard library:
fortran-audit ./src --html report.html
I validated it against roughly 2.2 million lines of real code — LAPACK, ROMS,
Nek5000, MODFLOW 6, WPS, ARPACK-NG, MOPAC — and that was humbling. Three
separate false-positive classes turned up, each one embarrassing:
-
.F files were assumed fixed-form, so every free-form continuation past
column 72 looked like silently truncated code. ROMS alone produced 91,505
phantom criticals. It is actually one of the cleanest codebases I scanned. -
!comments were scored as evidence of free form. They are legal in fixed
form too, so files with!banner headers flipped form, and their
c-in-column-1 comments were then parsed as live code. -
The float-literal pattern matched the
.0insidenid.eq.0, so every
integer comparison was reported as a dangerous floating-point equality
test. That was 88% of the rule’s output.
All three are fixed, with regression tests. I then checked all 23,994 remaining
findings across five projects against the source individually, using a separate
checker that shares no code with the analyser.
It is heuristic, not a compiler front end — INCLUDE files are not expanded and
preprocessor branches are read as plain text. Every finding cites a file and
line so you can check it. I would like to hear where it misfires on your code.
MIT licensed.