A fruitful source of bugs in Fortran source code is use, or mis-use, of Fortran's implicit-typing feature, whereby the type of a variable, array, or function is determined by the first character of its name.
Simple cases of this include statements like LOGX=9.227
,
without a statement such as REAL LOGX
.
In this case, LOGX
is implicitly given INTEGER(KIND=1)
type, with the result of the assignment being that it is given
the value 9
.
More involved cases include a function that is defined starting
with a statement like DOUBLE PRECISION FUNCTION IPS(...)
.
Any caller of this function that does not also declare IPS
as type DOUBLE PRECISION
(or, in GNU Fortran, REAL(KIND=2)
)
is likely to assume it returns
INTEGER
, or some other type, leading to invalid results
or even program crashes.
The -Wimplicit
option might catch failures to
properly specify the types of
variables, arrays, and functions in the code.
However, in code that makes heavy use of Fortran's
implicit-typing facility, this option might produce so
many warnings about cases that are working, it would be
hard to find the one or two that represent bugs.
This is why so many experienced Fortran programmers strongly
recommend widespread use of the IMPLICIT NONE
statement,
despite it not being standard FORTRAN 77, to completely turn
off implicit typing.
(g77
supports IMPLICIT NONE
, as do almost all
FORTRAN 77 compilers.)
Note that -Wimplicit
catches only implicit typing of
names.
It does not catch implicit typing of expressions such
as X**(2/3)
.
Such expressions can be buggy as well--in fact, X**(2/3)
is equivalent to X**0
, due to the way Fortran expressions
are given types and then evaluated.
(In this particular case, the programmer probably wanted
X**(2./3.)
.)