Table of Contents
Previous: an Example
The messages given by ftnchek include not only syntax errors but also
warnings and informational messages about things that are legal Fortran
but that may indicate errors or carelessness. Most of these messages can
be turned off by command-line options. Which option controls each message
depends on the nature of the condition being warned about. See the descriptions
of the command-line flags in the previous sections, and of individual messages
below. Each message is prefixed with a word or phrase indicating the nature
of the condition and its severity.
``Error'' means a syntax error. The simplest
kind of syntax errors are typographical errors, for example unbalanced
parentheses or misspelling of a keyword. This type of error is caught
by the parser and appears with the description ``parse error'' or ``syntax error''
(depending on whether the parser was built using GNU bison or UNIX yacc
respectively). This type of error message cannot be suppressed. Be aware
that this type of error often means that ftnchek has not properly interpreted
the statement where the error occurs, so that its subsequent checking
operations will be compromised. You should eliminate all syntax errors
before proceeding to interpret the other messages ftnchek gives.
``Warning:
Nonstandard syntax'' indicates an extension to Fortran that ftnchek supports
but that is not according to the Fortran 77 Standard. The extensions that
ftnchek accepts are described in the section on Extensions. One
example is the DO ... ENDDO construction. If a program uses these extensions,
warnings will be given according to specifications under the -f77 setting.
The default behavior is to give no warnings.
``Warning'' in other cases means
a condition that is suspicious but that may or may not be a programming
error. Frequently these conditions are legal under the standard. Some
are illegal but do not fall under the heading of syntax errors. Usage errors
are one example. These refer to the possibility that a variable may be
used before it has been assigned a value (generally an error), or that
a variable is declared but never used (harmless but may indicate carelessness).
The amount of checking for usage errors is controlled by the -usage flag,
which specifies the maximum amount of checking by default.
Truncation warnings
cover situations in which accuracy may be lost unintentionally, for example
when a double precision value is assigned to a real variable. These warnings
are controlled by the -truncation setting, which is on by default.
``Nonportable
usage'' warns about some feature that may not be accepted by some compilers
even though it is not contrary to the Fortran 77 Standard, or that may
cause the program to perform differently on different platforms. For example,
equivalencing real and integer variables is usually a non-portable practice.
The use of extensions to the standard language is, of course, another
source of non-portability, but this is handled as a separate case. To check
a program for true portability, both the -portability and the -f77 flags
should be used. They are both turned off by default. The -wordsize setting
is provided to check only those nonportable usages that depend on a particular
machine wordsize.
``Possibly misleading appearance'' is used for legal constructions
that may not mean what they appear to mean at first glance. For example,
Fortran is insensitive to blank space, so extraneous space within variable
names or the lack of space between a keyword and a variable can convey
the wrong impression to the reader. These messages can be suppressed by
turning off the -pretty flag, which is on by default.
Other messages that
are given after all the files are processed, and having to do with agreement
between modules, do not use the word ``warning'' but generally fall into that
category. Examples include type mismatches between corresponding variables
in different COMMON block declarations, or between dummy and actual arguments
of a subprogram. These warnings are controlled by the -common and -arguments
settings respectively. By default both are set for maximum strictness
of checking.
Another group of warnings about conditions that are often
harmless refer to cases where the array properties of a variable passed
as a subprogram argument differ between the two routines. For instance,
an array element might be passed to a subroutine that expects a whole
array. This is a commonly-used technique for processing single rows or
columns of two-dimensional arrays. However, it could also indicate a programming
error. The -array setting allows the user to adjust the degree of strictness
to be used in checking this kind of agreement between actual and dummy
array arguments. By default the strictness is maximum.
``Oops'' indicates a
technical problem, meaning either a bug in ftnchek or that its resources
have been exceeded.
The syntax error messages and warnings include the
filename along with the line number and column number. ftnchek has two
different options for the appearance of these error messages. If -novice
is in effect, which is the default, the messages are in a style approximating
normal English. (In default style, the filename is not printed in messages
within the body of the program if -list is in effect.) The other style
of error messages is selected by the -nonovice option. In this style,
the appearance of the messages is similar to that of the UNIX lint program.
ftnchek is still blind to some kinds of syntax errors. The two most important
ones are detailed checking of FORMAT statements, and almost anything
to do with control of execution flow by means of IF , DO , and GOTO statements:
namely correct nesting of control structures, matching of opening statements
such as IF ... THEN with closing statements such as ENDIF , and the proper
use of statement labels (numbers). Most compilers will catch these errors.
See the section on Limitations for a more detailed discussion.
If ftnchek
gives you a syntax error message when the compiler does not, it may be
because your program contains an extension to standard Fortran which is
accepted by the compiler but not by ftnchek . (See the section on Extensions.)
On a VAX/VMS system, you can use the compiler option /STANDARD to cause
the compiler to accept only standard Fortran. On most UNIX or UNIX-like
systems, this can be accomplished by setting the flag -ansi.
Many of the
messages given by ftnchek are self-explanatory. Those that need some additional
explanation are listed below in alphabetical order.
- Common block NAME:
data type mismatch at position n
- The n -th variable in the COMMON block
differs in data type in two different declarations of the COMMON block.
By default (-common strictness level 3), ftnchek is very picky about
COMMON blocks: the variables listed in them must match exactly by data
type and array dimensions. That is, the legal pair of declarations in
different modules:
COMMON /COM1/ A,B
and
COMMON /COM1/ A(2)
will cause ftnchek to give warnings at strictness level 3. These two
declarations are legal in Fortran since they both declare two real variables.
At strictness level 1 or 2, no warning would be given in this example,
but the warning would be given if there were a data type mismatch, for
instance, if B were declared INTEGER . Controlled by -common setting.
- Common block NAME has long data type following short data type
- Some
compilers require alignment of multi-byte items so that each item begins
at an address that is a multiple of the item size. Thus if a short (e.g.
single-precision real) item is followed by a long (e.g. double precision
real) item, the latter may not be aligned correctly. Controlled by -portability=common-alignment
option.
- Common block NAME has mixed character and non-character variables
- The ANSI standard requires that if any variable in a COMMON block is
of type CHARACTER , then all other variables in the same COMMON block
must also be of type CHARACTER . Controlled by -f77=mixed-common option.
- Common block NAME: varying length
- For -common setting level 2, this
message means that a COMMON block is declared to have different numbers
of words in two different subprograms. A word is the amount of storage
occupied by one integer or real variable. For -common setting level 3,
it means that the two declarations have different numbers of variables,
where an array of any size is considered one variable. This is not necessarily
an error, but it may indicate that a variable is missing from one of the
lists. Note that according to the Fortran 77 Standard, it is an error
for named COMMON blocks (but not blank COMMON) to differ in number of
words in declarations in different modules. Given for -common setting 2
or 3.
- Error: Badly formed logical/relational operator or constant
- Error:
Badly formed real constant
- The syntax analyzer has found the start of
one of the special words that begin and end with a period (e.g. .EQ. ), or
the start of a numeric constant, but did not succeed in finding a complete
item of that kind.
- Error: cannot be adjustable size in module NAME
- A
character variable cannot be declared with a size that is an asterisk
in parentheses unless it is a dummy argument, a parameter, or the name
of the function defined in the module.
- Error: cannot be declared in SAVE
statement in module NAME
- Only local variables and common blocks can be
declared in a SAVE statement.
- Error: No path to this statement
- ftnchek
will detect statements which are ignored or by-passed because there is
no foreseeable route to the statement. For example, an unnumbered statement
(a statement without a statement label), occurring immediately after a
GOTO statement, cannot possibly be executed.
- Error: Parse error
- This
means that the parser, which analyzes the Fortran program into expressions,
statements, etc., has been unable to find a valid interpretation for some
portion of a statement in the program. If your compiler does not report
a syntax error at the same place, the most common explanations are: (1)
use of an extension to ANSI standard Fortran that is not recognized by
ftnchek , or (2)
the statement requires more lookahead than ftnchek uses
(see section on Bugs).
NOTE: This message means that the affected statement
is not interpreted. Therefore, it is possible that ftnchek 's subsequent
processing will be in error, if it depends on any matters affected by
this statement (type declarations, etc.).
- Error: Syntax error
- This is
the same as ``Error: Parse error'' (see above). It is generated if your version
of ftnchek was built using the UNIX yacc parser generator rather than
GNU bison .
- Identifiers which are not unique in first six chars
- Warns
that two identifiers which are longer than 6 characters do not differ
in the first 6 characters. This is for portability: they may not be considered
distinct by some compilers. Controlled by -sixchar option.
- Nonportable
usage: argument precision may not be correct for intrinsic function
- The
precision of an argument passed to an intrinsic function may be incorrect
on some computers. Issued when a numeric variable declared with explicit
precision (e.g. REAL*8 X ) is passed to a specific intrinsic function (e.g.
DSQRT(X) ). Controlled by -portability=mixed-size and -wordsize .
- Nonportable
usage: character constant/variable length exceeds 255
- Some compilers
do not support character strings more than 255 characters in length. Controlled
by -portability=long-string .
- Nonportable usage: File contains tabs
- ftnchek
expands tabs to be equivalent to spaces up to the next column which is
a multiple of 8. Some compilers treat tabs differently, and also it is
possible that files sent by electronic mail will have the tabs converted
to blanks in some way. Therefore files containing tabs may not be compiled
correctly after being transferred. ftnchek does not give this message
if tabs only occur within comments or character constants. Controlled by
-portability=tab .
- Nonportable usage: non-integer DO loop bounds
- This warning
is only given when the DO index and bounds are non-integer. Use of non-integer
quantities in a DO statement may cause unexpected errors, or different
results on different machines, due to roundoff effects. Controlled by -portability=real-do
.
- Possibly it is an array which was not declared
- This message is appended
to warnings related to a function invocation or to an argument type mismatch,
for which the possibility exists that what appears to be a function is
actually meant to be an array. If the programmer forgot to dimension an
array, references to the array will be interpreted as function invocations.
This message will be suppressed if the name in question appears in an
EXTERNAL or INTRINSIC statement. Controlled by the -novice option.
- Possibly
misleading appearance: characters past 72 columns
- The program is being
processed with the statement field width at its standard value of 72,
and some nonblank characters have been found past column 72. In this case,
ftnchek is not processing the characters past column 72, and is notifying
the user that the statement may not have the meaning that it appears to
have. These characters might be intended by the programmer to be significant,
but they will be ignored by the compiler. Controlled by -pretty=long-line
.
- Possibly misleading appearance: Common block declared in more than one
statement
- Such multiple declarations are legal and have the same effect
as a continuation of the original declaration of the block. This warning
is only given if the two declarations are separated by one or more intervening
statements. Controlled by -pretty=multiple-common .
- Possibly misleading appearance:
Continuation follows comment or blank line
- ftnchek issues this warning
message to alert the user that a continuation of a statement is interspersed
with comments, making it easy to overlook. Controlled by -pretty=continuation
.
- Possibly misleading appearance: Extraneous parentheses
- Warns about
parentheses surrounding a variable by itself in an expression. When a
parenthesized variable is passed as an argument to a subprogram, it is
treated as an expression, not as a variable whose value can be modified
by the called routine. Controlled by -pretty=parentheses .
- Subprogram NAME:
argument data type mismatch at position n
- The subprogram's n -th actual
argument (in the CALL or the usage of a function) differs in datatype
or precision from the n -th dummy argument (in the SUBROUTINE or FUNCTION
declaration). For instance, if the user defines a subprogram by
SUBROUTINE SUBA(X)
REAL X
and elsewhere invokes SUBA by
CALL SUBA(2)
ftnchek will detect the error. The reason here is that the number
2 is integer, not real. The user should have written
CALL SUBA(2.0)
When checking an argument which is a subprogram, ftnchek must be able
to determine whether it is a function or a subroutine. The rules used
by ftnchek to do this are as follows: If the subprogram, besides being
passed as an actual argument, is also invoked directly elsewhere in the
same module, then its type is determined by that usage. If not, then if
the name of the subprogram does not appear in an explicit type declaration,
it is assumed to be a subroutine; if it is explicitly typed it is taken
as a function. Therefore, subroutines passed as actual arguments need
only be declared by an EXTERNAL statement in the calling module, whereas
functions must also be explicitly typed in order to avoid generating this
error message. Controlled by -arguments setting.
- Subprogram NAME: argument
arrayness mismatch at position n
- Similar to the preceding situation,
but the subprogram dummy argument differs from the corresponding actual
argument in its number of dimensions or number of elements. Controlled
by -array together with -arguments settings.
- Subprogram NAME: argument
mismatch at position n
- A character dummy argument is larger than the
corresponding actual argument, or a Hollerith dummy argument is larger
than the corresponding actual argument. Controlled by -arguments setting.
- Subprogram NAME: argument usage mismatch
- ftnchek detects a possible
conflict between the way a subprogram uses an argument and the way in
which the argument is supplied to the subprogram. The conflict can be
one of two types, as outlined below.
- Dummy arg is modified, Actual arg
is const or expr
- A dummy argument is an argument as named in a SUBROUTINE
or FUNCTION statement and used within the subprogram. An actual argument
is an argument as passed to a subroutine or function by the caller. ftnchek
is saying that a dummy argument is modified by the subprogram, implying
that its value is changed in the calling module. The corresponding actual
argument should not be a constant or expression, but rather a variable
or array element which can be legitimately assigned to. Controlled by the
-usage=arg-const-modified option.
- Dummy arg used before set, Actual arg
not set
- Here a dummy argument may be used in the subprogram before having
a value assigned to it by the subprogram. The corresponding actual argument
should have a value assigned to it by the caller prior to invoking the
subprogram. Controlled by the -usage=var-uninitialized option.
This warning
is not affected by the -arguments setting.
- Subprogram NAME invoked inconsistently
- Here the mismatch is between the datatype of the subprogram itself as
used and as defined. For instance, if the user declares
INTEGER FUNCTION COUNT(A)
and invokes COUNT in another module as
N = COUNT(A)
without declaring its datatype, it will default to real type, based
on the first letter of its name. The calling module should have included
the declaration
INTEGER COUNT
Given for -arguments setting 2 or 3.
- Subprogram NAME: varying length
argument lists:
- An inconsistency has been found between the number of
dummy arguments (parameters) a subprogram has and the number of actual
arguments given it in an invocation. ftnchek keeps track of all invocations
of subprograms (CALL statements and expressions using functions) and
compares them with the definitions of the subprograms elsewhere in the
source code. The Fortran compiler normally does not catch this type of
error. Given for -arguments setting 1 or 3.
- Variable not declared. Type
has been implicitly defined
- When printing the symbol table for a module,
ftnchek will flag with an asterisk all identifiers that are not explicitly
typed and will show the datatype that was assigned through implicit typing.
This provides support for users who wish to declare all variables as is
required in Pascal or some other languages. This message appears only when
the -symtab option is in effect. Alternatively, use the -declare flag if
you want to get a list of all undeclared variables.
- Variables declared
but never referenced
- Detects any identifiers that were declared in your
program but were never used, either to be assigned a value or to have
their value accessed. Variables in COMMON are excluded. Controlled by the
-usage=var-unused option.
- Variables set but never used
- ftnchek will notify
the user when a variable has been assigned a value, but the variable is
not otherwise used in the program. Usually this results from an oversight.
Controlled by the -usage=var-set-unused option.
- Variables used before set
- This message indicates that an identifier is used to compute a value
prior to its initialization. Such usage may lead to an incorrect value
being computed, since its initial value is not controlled. Controlled by
the -usage=var-uninitialized option.
- Variables may be used before set
- Similar to used before set except that ftnchek is not able to determine
its status with certainty. ftnchek assumes a variable may be used before
set if the first usage of the variable occurs prior in the program text
to its assignment. Controlled by the -usage=var-uninitialized option.
- Warning:
DO index is not integer
- This warning is only given when the DO bounds
are integer, but the DO index is not. It may indicate a failure to declare
the index to be an integer. Controlled by -truncation=real-do option.
- Warning:
integer quotient expr converted to real
- The quotient of two integers
results in an integer type result, in which the fractional part is dropped.
If such an integer expression involving division is later converted to
a real datatype, it may be that a real type division had been intended.
Controlled by -truncation=int-div-real option.
- Warning: Integer quotient
expr used in exponent
- The quotient of two integers results in an integer
type result, in which the fractional part is dropped. If such an integer
expression is used as an exponent, it is quite likely that a real type
division was intended. Controlled by -truncation=int-div-exponent option.
- Warning: NAME not set when RETURN encountered
- The way that functions
in Fortran return a value is by assigning the value to the name of the
function. This message indicates that the function was not assigned a
value before the point where a RETURN statement was found. Therefore
it is possible that the function could return an undefined value.
- Warning:
Nonstandard syntax: adjustable size cannot be concatenated here
- The Fortran
77 Standard (sec. 6.2.2) forbids concatenating character variables whose
size is an asterisk in parentheses, except in an assignment statement.
Controlled by -f77=mixed-expr .
- Warning: Nonstandard syntax : significant
characters past 72 columns
- This warning is given under the -f77=long-line
setting if the -columns setting has been used to increase the statement
field width, and a statement has meaningful program text beyond column
72. Standard Fortran ignores all text in those columns, but some compilers
do not. Thus the program may be treated differently by different compilers.
- Warning: Nonstandard syntax : Statement out of order.
- ftnchek will detect
statements that are out of the sequence specified for ANSI standard Fortran
77. Table 1 illustrates the allowed sequence of statements in the Fortran
language. Statements which are out of order are nonetheless interpreted
by ftnchek , to prevent ``cascades'' of error messages. The sequence counter
is also rolled back to prevent repetition of the error message for a block
of similar statements. Controlled by the -f77=statement-order option.
--------------------------------------------------------
| | implicit
| parameter |---------------------
| | other specification
format |---------------|---------------------
and | | statement-function
entry | data |---------------------
| | executable
--------------------------------------------------------
Table 1
- Warning: Possible division by zero
- This message is printed out wherever
division is done (except division by a constant). Use it to help locate
a runtime division by zero problem. Controlled by -division option.
- Warning:
real truncated to intg
- ftnchek has detected an assignment statement
which has a real expression on the right, but an integer variable on the
left. The fractional part of the real value will be lost. If you explicitly
convert the real expression to integer using the INT or NINT intrinsic
function, no warning will be printed. A similar message is printed if
a double precision expression is assigned to a single precision variable,
etc. Controlled by -truncation=demotion option.
- Warning: subscript is not
integer
- Since array subscripts are normally integer quantities, the use
of a non-integer expression here may signal an error. Controlled by -truncation=real-subscript
option.
- Warning: Unknown intrinsic function
- This message warns the user
that a name declared in an INTRINSIC statement is unknown to ftnchek
. Probably it is a nonstandard intrinsic function, and so the program
will not be portable. The function will be treated by ftnchek as a user-defined
function. This warning is not suppressed by any option, since it affects
ftnchek 's analysis of the program. However, if the intrinsic function
is in one of the supported sets of nonstandard intrinsics, you can use
the -intrinsic setting to cause ftnchek to recognize it.
Next: Limitations and Extensions