FTNCHEK 3.3(1L) FTNCHEK 3.3(1L)NAMEftnchek - Fortran 77 program checker
SYNOPSISftnchek [ -arguments[=list] ] [ -array[=list] ]
[ -[no]brief ] [ -calltree[=list] ] [ -[no]check ]
[ -columns[=num] ] [ -common[=list] ]
[ -[no]crossref[=list] ] [ -[no]declare ]
[ -[no]division ] [ -errors[=num] ] [ -[no]extern ]
[ -[no]f77[=list] ] [ -[no]f90[=list] ]
[ -[no]f95[=list] ] [ -[no]help ]
[ -[no]identifier-chars[=list] ] [ -include=str ]
[ -intrinsic[=list] ] [ -[no]library ] [ -[no]list ]
[ -makedcls[=list] ] [ -mkhtml[=list] ]
[ -[no]novice ] [ -output=str ]
[ -pointersize[=num] ] [ -[no]portability[=list] ]
[ -[no]pretty[=list] ] [ -project[=list] ]
[ -[no]pure ] [ -[no]quiet ] [ -[no]reference ]
[ -[no]resources ] [ -[no]sixchar ] [ -[no]sort ]
[ -source[=list] ] [ -style[=list] ] [ -[no]symtab ]
[ -[no]truncation[=list] ] [ -usage[=list] ]
[ -[no]vcg ] [ -[no]version ] [ -[no]volatile ]
[ -wordsize[=num] ] [ -wrap[=num] ] [ files ... ]
DESCRIPTIONftnchek (short for Fortran checker) is designed to detect certain
errors in a Fortran program that a compiler usually does not. ftnchek
is not primarily intended to detect syntax errors. Its purpose is to
assist the user in finding semantic errors. Semantic errors are legal
in the Fortran language but are wasteful or may cause incorrect opera‐
tion. For example, variables which are never used may indicate some
omission in the program; uninitialized variables contain garbage which
may cause incorrect results to be calculated; and variables which are
not declared may not have the intended type. ftnchek is intended to
assist users in the debugging of their Fortran program. It is not
intended to catch all syntax errors. This is the function of the com‐
piler. Prior to using ftnchek, the user should verify that the program
compiles correctly.
This document first summarizes how to invoke ftnchek. That section
should be read before beginning to use ftnchek. Later sections
describe ftnchek's options in more detail, give an example of its use,
and explain how to interpret the output. The final sections mention
the limitations and known bugs in ftnchek.
INVOKING FTNCHEKftnchek is invoked through a command of the form:
$ ftnchek [-option -option ...] filename [filename ...]
The brackets indicate something which is optional. The brackets them‐
selves are not actually typed. Here options are command-line switches
or settings, which control the operation of the program and the amount
of information that will be printed out. If no option is specified,
the default action is to print error messages, warnings, and informa‐
tional messages, but not the program listing or symbol tables.
Each option begins with the '-' character. (On VAX/VMS or MS-DOS sys‐
tems you may use either '/' or '-'.) For the sake of conformity with
an increasingly common convention, options can also begin with '--'.
The options are described at greater length in the next section.
ftnchek options fall into two categories: switches, which are either
true or false, and settings, which have a numeric or string value. The
name of a switch is prefixed by 'no' or 'no-' to turn it off: e.g.
-nopure would turn off the warnings about impure functions. The 'no'
prefix can also be used with numeric settings, having the effect of
turning off the corresponding warnings. Settings that control lists of
warnings have a special syntax discussed below. Only the first 3 char‐
acters of an option name (not counting the '-') need be provided. A
colon may be used in place of an equals sign for numeric or string set‐
ting assignments; however, we show only the equals sign form below.
The switches and settings which ftnchek currently recognizes are listed
below. For each option, the default is the value used if the option is
not explicitly specified, while the turn-on is the value used if the
option is given without assigning it a value.
-arguments=list
Control warnings about subprogram type and argument mismatches.
Default = turn-on = all.
-array=list
Control warnings in checking array arguments of subprograms.
Default = turn-on = all.
-brief Use shorter format for some error messages. Default = no.
-calltree=list
Produce subprogram call hierarchy in one of 3 formats: text
call-tree, who-calls-who and VCG. Default = none, turn-on =
tree,prune,sort.
If the -mkhtml option is invoked and tree is the applied call‐
tree option, a file named CallTree.html, will be produced
depicting the tree in HTML format.
-check Perform checking. Default = yes.
-columns=num
Set maximum line length to num columns. (Beyond this is
ignored.) Turn-on = max = 132. Default = 72.
-common=list
Set degree of strictness in checking COMMON blocks. Default =
turn-on = all.
-crossref=list
Print cross-reference list of subprogram calls, label usage,
and/or COMMON block use. Default = none.
-declare
Print a list of all identifiers whose datatype is not explicitly
declared. Default = no.
-division
Warn wherever division is done (except division by a constant).
Default = no.
-errors=num
Set the maximum number of error messages per cascade. Default =
turn-on = 3.
-extern
Warn if external subprograms which are invoked are never
defined. Default = yes.
-f77=list
Control specific warnings about supported extensions to the For‐
tran 77 Standard. Default = none, turn-on = all.
-f90=list
Control specific warnings about supported extensions to the For‐
tran 77 Standard that were not adopted as part of the Fortran 90
Standard. Default = none, turn-on = all.
-f95=list
Control specific warnings about standard Fortran 77 features
that were deleted from the Fortran 95 Standard. Default =
none, turn-on = all.
-help Print command summary. Default = no.
-identifier-chars=list
Define non-alphanumeric characters that may be used in identi‐
fiers. Default = turn-on = dollar sign and underscore.
-include=path
Define a directory to search for INCLUDE files before searching
in the system-wide directory. Cumulative. Default = turn-on =
none.
-intrinsic=list
Control treatment of nonstandard intrinsic functions. Default =
all except vms for Unix version, all except unix for VMS ver‐
sion, all except unix and vms for other versions. Turn-on =
all.
-library
Begin library mode: do not warn about subprograms in file that
are defined but never used. Default = no.
-list Print source listing of program. Default = no.
-makedcls=list
Prepare a file of declarations. The list specifies options for
the format of this file. Default = none, turn-on = declara‐
tions.
-mkhtml=list
Create individual HTML document files from ftnchek analysis and
code comments. Usually you will also want to specify -call=tree
to create the root HTML file CallTree.html. Default = none,
turn-on = documents.
-novice
Give output suitable for novice users. Default = yes.
-output=filename
Send output to the given file. Default and turn-on sends output
to the screen. (Default filename extension is .lis).
-pointersize=num
Set the size of ``Cray pointer'' variables to num bytes. Min =
1, max = 16. Default = turn-on = 4
-portability=list
Warn about non-portable usages. Default = none, turn-on = all.
-pretty=list
Give warnings for possibly misleading appearance of source code.
Default = turn-on = all.
-project=list
Create project file (see explanation below). Default = no.
-pure Assume functions are pure, i.e. have no side effects. Default =
yes.
-quiet Produce less verbose output. Default = no.
-reference
Print table of subprograms referenced by each subprogram.
Default = no.
-resources
Print amount of resources used in analyzing the program.
Default = no.
-sixchar
List any variable names which clash at 6 characters length.
Default = no.
-sort Print list of subprograms sorted in prerequisite order. Default
= no.
-source=list
Select source formatting options: fixed or free form, DEC For‐
tran tab-formatted lines, VMS-style INCLUDE statement, UNIX-
style backslash escape sequences, and implicit typing of parame‐
ters. Default = none, turn-on = all.
-style=list
Produce extra-picky warnings about obsolescent or old-fashioned
programming constructions. Default = none, turn-on = all.
-symtab
Print symbol table and label table for each subprogram. Default
= no.
-truncation=list
Check for possible loss of accuracy by truncation. Default =
turn-on = all.
-usage=list
Control warnings about unused or uninitialized variables, common
blocks, etc. Default = turn-on = all.
-vcg Produce VCG format of call graph.
-version
Print version number. Default = no.
-volatile
Assume COMMON blocks lose definition between activations.
Default = no. (Obsolete. Use -common=volatile instead.)
-wordsize=num
Set the default word size for numeric quantities to num bytes.
Default = turn-on = 4 bytes.
-wrap=num
Set output column at which to wrap long error messages and warn‐
ings to the next line. If set to 0, turn off wrapping. Default
= turn-on = 79.
When more than one option is used, they should be separated by a blank
space, except on systems such as VMS where options begin with slash ( /
). No blank spaces may be placed around the equals sign ( = ) in a
setting. ftnchek "?" will produce a command summary listing all
options and settings.
For settings that take a list of keywords, namely -arguments, -array,
-calltree, -common, -crossref, -f77, -f90, -f95, -intrinsic, -makedcls,
-mkhtml, -portability, -pretty, -project, -source, -style, -truncation,
and -usage, the list consists of keywords separated by commas or
colons. If the list of keywords is omitted, the effect is to set the
option to its turn-on value (same as ``all'' in most cases). Also, if
the list is omitted, the setting name can be prefixed with no or no- to
turn off all the options it controls. For example, -f77 turns on all
warnings about nonstandard constructions, while -nof77 turns them all
off. Three special keywords are:
help Print out all the option keywords controlled by the setting,
with a brief explanation of their meanings. This keyword cannot
be given in a list with other keywords.
all Set all options. This turns on all options controlled by the
setting.
none Clear all options. This turns off all options controlled by the
setting.
These three special keywords must be given in full. For all other key‐
words, only as many letters of the keyword as are necessary to identify
it unambiguously need be given, or a wildcard pattern may be used.
Including a keyword in the list turns the corresponding option on. For
example, -f77=intrinsic would turn on only the warnings about use of
nonstandard intrinsic functions. Prefixing a keyword by no- turns its
option off. For example, -pretty=no-long-line turns off warnings about
lines exceeding 72 columns in length while leaving all other warnings
about misleading appearance in effect. If a setting has default none,
you can turn on all options except one or two by using all first. For
example, -f77=all,no-include enables warnings about all nonstandard
extensions except INCLUDE statements. If a setting has default all,
you can turn off all warnings except one or two by using none first.
For example, -truncation=none,demotion would turn off all precision
related warnings except about demotions. Wildcard patterns contain an
asterisk to stand for any string of characters. If a wildcard pattern
is used, all the warnings that match it are affected. If no- is pre‐
fixed to the pattern, all the matching warnings are turned off, other‐
wise they are all turned on. The minimum unambiguous length rule does
not apply to wildcard matching. For example, use -usage=no-*var* to
turn off all warnings relating to variable usage (both local and com‐
mon). (Unix users may need to quote any options containing wildcards
in order to prevent the shell from attempting to expand them.) Wild‐
cards are recognized only in lists of warning keywords, not in the top-
level options themselves.
When ftnchek starts up, it looks for environment variables and also for
a preferences file. Any options defined in the environment or in the
preferences file are used as defaults in place of the built-in
defaults. They are over-ridden by any command line options. See the
section on changing the defaults for details about the environment
options and the preferences file.
When giving a name of an input file, the extension is optional. If no
extension is given, ftnchek will first look for a project file with
extension .prj, and will use that if it exists. If not, then ftnchek
will look for a Fortran source file with the extension .for for VMS
systems, .f for UNIX systems. More than one file name can be given to
ftnchek, and it will process the modules in all files as if they were
in a single file.
Wildcards are allowed in the specification of filenames on the command
line for the VMS and MS-DOS versions, as also of course under UNIX and
any other system that performs wildcard expansion in the command pro‐
cessor.
If no filename is given, ftnchek will read input from the standard
input.
OPTIONS
This section provides a more detailed discussion of ftnchek command-
line options. Options and filenames may be interspersed on a command
line. Most options are positional: each option remains in effect from
the point it is encountered until it is overridden by a later change.
Thus for example, the listing may be suppressed for some files and not
for others. Exceptions are: the -intrinsic, -pointersize, and -word‐
size settings, which cannot be changed once processing of input files
has started; the -arguments, -array, -calltree, -common, -crossref,
-extern, -reference, -resources, -sort, -vcg, and -volatile options,
where the action depends only on the value of the option after the pro‐
cessing of input files is finished; and the -include setting, which is
cumulative.
The option names in the following list are in alphabetical order.
-arguments=list
Controls warnings about mismatches between actual and dummy sub‐
program arguments, and also about mismatches between expected
and actual subprogram type. (An actual argument is an argument
passed to the subprogram by the caller; a dummy argument is an
argument received by the subprogram.) By default, all warnings
are turned on.
The list consists of keywords separated by commas or colons.
Since all these warnings are on by default, include a keyword
prefixed by no- to turn off a particular warning. There are
three special keywords: all to turn on all the warnings about
arguments, none to turn them all off, and help to print the list
of all the keywords with a brief explanation of each. If list
is omitted, -arguments is equivalent to -arguments=all, and
-noarguments is equivalent to -arguments=none. The warning key‐
words with their meanings are as follows:
arrayness:
warn about inconsistent use of arguments that are arrays.
These warnings can be further controlled by the -array
option.
type:
warn about dummy arguments of a different data type from the
actual arguments.
function-type:
warn if the invocation assumes the function's return value
is a different type than it actually is. Also warns if a
function is called as a subroutine, or vice-versa.
number:
warn about invoking a subprogram with a different number of
arguments than the subprogram expects.
For compatibility with previous versions of ftnchek, a numeric
form of this setting is also accepted: the list is replaced by a
number from 0 to 3. A value of 0 turns all the warnings off, 1
turns on only number, 2 turns on all except number, and 3 turns
all the warnings on.
This setting does not apply to checking invocations of intrinsic
functions or statement functions, which can only be turned off
by the -nocheck option.
See also: -array, -library, -usage.
-array=list
Controls the degree of strictness in checking agreement between
actual and dummy subprogram arguments that are arrays. The
warnings controlled by this setting are for constructions that
might legitimately be used by a knowledgeable programmer, but
that often indicate programming errors. By default, all warn‐
ings are turned on.
The list consists of keywords separated by commas or colons.
Since all these warnings are on by default, include a keyword
prefixed by no- to turn off a particular warning. There are
three special keywords: all to turn on all the warnings about
array arguments, none to turn them all off, and help to print
the list of all the keywords with a brief explanation of each.
If list is omitted, -array is equivalent to -array=all, and
-noarray is equivalent to -array=none. The warning keywords
with their meanings are as follows:
dimensions:
warn if the arguments differ in their number of dimensions,
or if the actual argument is an array element while the
dummy argument is a whole array.
size:
warn if both arguments are arrays, but they differ in number
of elements.
For compatibility with previous versions of ftnchek, a numeric
form of this setting is also accepted: the list is replaced by a
number from 0 to 3. A value of 0 turns all the warnings off, 1
turns on only dimensions, 2 turns on only size, and 3 turns all
the warnings on.
Note: A warning is always given regardless of this setting if
the actual argument is an array while the dummy argument is a
scalar variable, or if the actual argument is a scalar variable
or expression while the dummy argument is an array. These cases
are seldom intentional. (To turn off even these warnings, use
-arguments=no-arrayness.) No warning is ever given if the
actual argument is an array element while the dummy argument is
a scalar variable. Variable-dimensioned arrays and arrays
dimensioned with 1 or asterisk match any number of array ele‐
ments. There is no check of whether multi-dimensional arrays
agree in the size of each dimension separately.
See also: -arguments, -library, -usage.
-brief
Selects a shorter format for some warning messages. At present,
the only warnings controlled by this flag are those that are
printed at the end of processing each subprogram. These include
warnings about variables that are set but not used or used
before set, variable names that do not conform to the Fortran 77
standard, etc. (These warnings may be suppressed entirely
depending on other flags, such as the -usage or -f77 flags.) In
the default format each variable is listed on a separate line,
along with the line number where the variable is declared, set
or used, according to the nature of the warning. The briefer
format simply lists all variables to which the warning applies,
with up to 4 variables per line.
See also: -quiet.
-calltree=list
Causes ftnchek to print out the call structure of the complete
program.
The list consists of keywords separated by commas or colons.
There are two special keywords: none to turn off all the
options, and help to print the list of all the keywords with a
brief explanation of each. (The keyword all turns on all the
options, but should not normally be used since only one format
should be specified.) If list is omitted, -calltree is equiva‐
lent to -calltree=tree, and -nocalltree is equivalent to -call‐
tree=none. By default no call graph is printed.
If the -mkhtml option is invoked and tree is the applied call‐
tree option, a file named CallTree.html, will also be produced
depicting the tree in HTML format. This file is useful as a
starting point for browsing the HTML files describing each com‐
ponent of the program.
The keywords which control which format is used are as follows:
tree:
produce the call graph in tree format.
reference:
produce the call graph in who-calls-who format (same as
-reference switch).
vcg:
produce the call graph in VCG format (same as -vcg switch).
Only one of the formats tree, reference, or vcg may be speci‐
fied.
The following keywords control options affecting the output:
prune:
prune repeated subtrees (applicable only with tree). This
the default.
sort:
sort children of each routine into alphabetical order. This
is the default.
See the discussion of the -reference and -vcg flags for details
about these formats.
For tree format, The call graph is printed out starting from the
main program, which is listed on the first line at the left mar‐
gin. Then on the following lines, each routine called by the
main program is listed, indented a few spaces, followed by the
subtree starting at that routine.
In the default mode, if a routine is called by more than one
other routine, its call subtree is printed only the first time
it is encountered Later calls give only the routine name and the
notice ``(see above)''. To have the subtree printed for each
occurrence of the routine, use option no-prune.
Note that the call tree will be incomplete if any of the input
files are project files containing more than one module that
were created in -library mode. See the discussion of project
files below.
Technical points: Each list of routines called by a given rou‐
tine is printed in alphabetical order unless the no-sort option
is given. If multiple main programs are found, the call tree of
each is printed separately. If no main program is found, a
report to that effect is printed out, and the call trees of any
top-level non-library routines are printed. This flag only con‐
trols the printing of the call tree: ftnchek constructs the call
tree in any case because it is used to determine which library
modules will be cross-checked. See the discussion of the
-library flag.
For compatibility with previous versions of ftnchek, a numeric
form of this setting is also accepted: the list is replaced by a
number from 0 to 15. This number is formed from 1 for tree for‐
mat, 2 for reference format, or 3 for vcg format, plus 4 for
no-prune, and 8 for no-sort.
See also: -crossref, -library, -reference, -sort, -symtab, -vcg.
-check
This switch is provided so that errors and warning messages can
be turned off when ftnchek is used for purposes other than find‐
ing bugs, such as making declarations or printing the call tree.
It is positional, so after turning all checks off, selected
checks can be turned back on. The effect of -nocheck is to put
all switches, numeric settings, and settings controlling lists
of warnings to their turn-off values, as if they had all been
specified with the -no prefix. Switches and settings that spec‐
ify options and modes of operation, rather than controlling
warnings, are unaffected. These are -columns, -crossref,
-include, -intrinsic, -library, -list, -makedcls, -novice, -out‐
put, -pointersize, -project, -quiet, -reference, -resources,
-sort, -source, -symtab, -vcg, -version, -wordsize, and -wrap.
Default = yes.
Parse errors (syntax errors due to unrecognized or malformed
statements) are not suppressed by this switch, since the results
may be incorrect if ftnchek has not parsed the program cor‐
rectly.
There are some miscellaneous errors and warning messages that
are not controlled by any other switch, and so can be turned off
only by this switch. Note that using -check following -nocheck
only has the effect of turning these special warnings back on,
and does not restore all the checks it turned off. These warn‐
ings are:
o Module contains no executable statements.
o In free source form, missing space where space is required
(e.g. between a keyword and an identifier) or space present
where none is allowed (e.g. within an identifier).
o Zero or negative length specification in a data type decla‐
ration of the form type*len.
o Invalid operand(s) in an expression.
o Array assigned to scalar.
o Type mismatch between DO index and bounds.
o Undefined common block declared in SAVE statement.
o Intrinsic function explicitly declared with an incompatible
type.
o Unknown intrinsic function explicitly declared in an INTRIN‐
SIC statement.
o Intrinsic function passed as a subprogram argument is not
declared in an INTRINSIC statement.
o Intrinsic function or statement function invoked incor‐
rectly.
o Function does not set return value prior to RETURN state‐
ment.
o Parameter constant value not evaluated (this is ftnchek's
fault, and it is just informing you of the fact).
o Entry point of a subprogram is later used as a different
subprogram's name.
o Unknown keyword used in an I/O statement.
o Illegal label reference (e.g. GOTO refers to a non-exe‐
cutable statement; I/O statement refers to a non-format
statement).
See also: -errors.
-columns=num
Set maximum statement length to num columns. (Beyond this is
ignored.) This setting is provided to allow checking of pro‐
grams which may violate the Fortran standard limit of 72 columns
for the length of a statement. According to the standard, all
characters past column 72 are ignored. If this setting is used
when the -f77=long-line option is in effect, a warning will be
given for any lines in which characters past column 72 are pro‐
cessed. Turn-on = max = 132. Default = 72.
This setting does not suppress warnings about the presence of
characters beyond column 72. To process code with meaningful
program text beyond column 72, use this setting and be sure the
-f77 long-line option is off. To process code with sequence
numbers in columns 73 to 80, leave the the columns setting at
the default value and use the -pretty=no-long-line flag.
See also: -f77, -pretty.
-common=list
This setting controls the strictness of checking of COMMON
blocks. By default, all warnings except volatile are turned on.
The list consists of keywords separated by commas or colons.
Since most of these warnings are on by default, include a key‐
word prefixed by no- to turn off a particular warning. There
are three special keywords: all to turn on all the warnings,
none to turn them all off, and help to print the list of all the
keywords with a brief explanation of each. If list is omitted,
-common is equivalent to -common=dimensions,exact,length,type,
and -nocommon is equivalent to -common=none. The warning key‐
words with their meanings are as follows:
dimensions:
corresponding arrays in each declaration of a block must
agree in size and number of dimensions. This option only
has an effect when used together with exact.
exact:
the comparison of two blocks is done variable-by-variable
rather than simply requiring agreement between corresponding
storage locations. Use this if all declarations of a given
COMMON block are supposed to be identical, which is a good
programming practice.
length:
warn if different declarations of the same block are not
equal in total length. The Fortran 77 Standard requires
each named common block, but not blank common, to be the
same length in all modules of the program.
type:
in each declaration of a given COMMON block, corresponding
memory locations (words or bytes) must agree in data type.
If used together with exact, this will require that corre‐
sponding variables agree in data type.
volatile:
Assume that COMMON blocks are volatile.
Many Fortran programmers assume that variables, whether local or
in COMMON, are static, i.e. that once assigned a value, they
retain that value permanently until assigned a different value
by the program. However, in fact the Fortran 77 Standard does
not require this to be the case. Local variables may become
undefined between activations of a module in which they are
declared. Similarly, COMMON blocks may become undefined if no
module in which they are declared is active. (The technical
term for entities with this behavior is ``automatic'', but
ftnchek uses the word ``volatile'' since it is clearer to the
nonspecialist.) Only COMMON blocks declared in a SAVE state‐
ment, or declared in the main program or in a block data subpro‐
gram remain defined as long as the program is running. Vari‐
ables and COMMON blocks that can become undefined at some point
are called volatile.
If the -common=volatile flag is turned on, ftnchek will warn you
if it finds a volatile COMMON block. If, at the same time, the
-usage=com-block-volatile option is turned on (which is the
default), ftnchek will try to check whether such a block can
lose its defined status between activations of the modules where
it is declared. ftnchek does not do a very good job of this:
the rule used is to see whether the block is declared in two
separated subtrees of the call tree. For instance, this would
be the case if two modules, both called from the main program,
shared a volatile COMMON block. A block can also become unde‐
fined between two successive calls of the same subprogram, but
ftnchek is not smart enough to tell whether a subprogram can be
called more than once, so this case is not checked for.
The -common=volatile flag does not affect the way ftnchek checks
the usage of local variables.
For compatibility with previous versions of ftnchek, a numeric
form of this setting is also accepted: the list is replaced by a
number from 0 to 3. A value of 0 turns all the warnings off, 1
or greater turns on type, 2 or greater turns on length, and 3
turns on dimensions and exact also. The numeric form cannot
turn on the volatile option.
See also: -library, -usage.
-crossref=list
Prints cross-reference tables. Default = none.
The list consists of keywords separated by commas or colons.
The keywords with their meanings are as follows:
calls:
table lists each subprogram followed by a list of routines
that call it. This listing omits library modules that are
not in the call tree of the main program. The list is
alphabetized.
common:
table lists each COMMON block followed by a list of the
routines that access it. These listed routines are those
in which some variables in the COMMON block are accessed,
not simply those routines that declare the block. (To
find out what routines declare a COMMON block but do not
use it, see the -usage flag.)
labels:
table lists each label followed by a list of all refer‐
ences to it. A label reference is denoted by the line
number and statement type of the referring statement.
The label list is in sequential order. The references are
listed in the order they are encountered in the program.
See also: -calltree, -reference, -sort, -symtab, -vcg.
-declare
If this flag is set, all identifiers whose datatype is not
declared in each module will be listed. This flag is useful for
helping to find misspelled variable names, etc. The same list‐
ing will be given if the module contains an IMPLICIT NONE state‐
ment. Default = no.
See also: -sixchar, -usage.
-division
This switch is provided to help users spot potential division by
zero problems. If this switch is selected, every division
except by a constant will be flagged. (It is assumed that the
user is intelligent enough not to divide by a constant which is
equal to zero!) Default = no.
See also: -portability, -truncation.
-errors=num
Set the maximum number of error messages in a ``cascade''. Dur‐
ing checking of agreement of subprogram arguments, common block
declarations, and so forth, sometimes a single case will gener‐
ate a long string of warnings. Often this simply indicates some
other cause than a genuine item-by-item mismatch, such as for
example a varible missing from one list. So in such cases
ftnchek stops printing the warnings after the cascade limit is
reached, and the trailer ``etc...'' is printed to indicate that
there were more errors not printed. If you think that these
warnings are likely to be genuine, use this setting to see more
of them. Turn-on = default = 3, max = 999. A value of 0 means
no limit.
This setting does not set an overall limit on the number of
error messages printed, only the number printed in any one cas‐
cade. Most types of warnings and error messages are not subject
to the cascade effect and so are not affected by this setting.
To turn off warnings generally, use the individual warning con‐
trol options or the -nocheck option.
See also: -check.
-extern
Causes ftnchek to report whether any subprograms invoked by the
program are never defined. Ordinarily, if ftnchek is being run
on a complete program, each subprogram other than the intrinsic
functions should be defined somewhere. Turn off this switch if
you just want to check a subset of files which form part of a
larger complete program. Subprogram arguments will still be
checked for correctness. Default = yes.
The -extern flag is now superseded by the -usage=ext-undefined
option. For the sake of convenience, the -extern flag is
retained, so that -noextern is equivalent to -usage=no-ext-unde‐
fined option. The -extern switch may be retired eventually.
See also: -library.
-f77=list
Use this setting to catch language extensions which violate the
Fortran 77 Standard. Such extensions may cause your program not
to be portable. Examples include the use of underscores in
variable names; variable names longer than six characters;
statement lines longer than 72 characters; and nonstandard
statements such as the DO ... ENDDO structure. ftnchek does not
report on the use of lowercase letters. By default, all warn‐
ings are turned off.
This setting provides detailed control over the warnings about
supported extensions to the Fortran 77 Standard. (Further
details about the extensions themselves are given below in the
section on Extensions.) The list consists of keywords separated
by commas or colons. There are three special keywords: all to
turn on all the warnings about nonstandard extensions, none to
turn them all off, and help to print the list of all the key‐
words with a brief explanation of each. If list is omitted,
-f77 is equivalent to -f77=all, and -nof77 is equivalent to
-f77=none. The warning keywords with their meanings are as fol‐
lows:
accept-type:
ACCEPT and TYPE I/O statements.
array-bounds:
Expressions defining array bounds that contain array ele‐
ments or function references.
assignment-stmt:
Assignment statements involving arrays. In Fortran 90, an
array can be assigned to another array of compatible
shape, or a scalar can be assigned to an array. Neither
of these assignments is permitted in Fortran 77.
A related warning occurs when an array is assigned to a
scalar. Since this is illegal also in Fortran 90, it is
always warned about regardless of the -f77 setting (unless
all checking is turned off with the -nocheck flag).
attribute-based-decl:
Type declarations in the new Fortran 90 attribute-based
style. This style of declaration is distinguished by the
use of a double colon (::) between the list of attributes
and the list of declared variables. This option also con‐
trols warnings for use of Fortran 90 length or kind speci‐
fiers in type declarations. (Although these specifiers
can be used in non-attribute-based declarations, they are
controlled by this option to avoid proliferation of -f77
options.)
automatic-array:
Local (not dummy) arrays which have variable size. These
would correspond to arrays whose storage would have to be
dynamically allocated at run time.
backslash:
Unix backslash escape in strings. This warning will be
given only if the -source=unix-backslash setting is speci‐
fied to cause the escape interpretation of backslash..
byte: BYTE data type declaration.
case-construct:
The SELECT CASE construct.
character:
Extensions to the Fortran 77 standard regarding character
data. At present, this only controls warnings about char‐
acter variables declared with zero or negative length. In
Fortran 77, all character variables must be of positive
length. In Fortran 90, they can be zero length, and dec‐
larations that specify negative lengths are permitted,
turning into zero for the declared length. Note: because
negative length specifiers may indicate a programming
error, the warning about them is given even if this option
is turned off, and is suppressed only by the -nocheck
flag.
common-subprog-name:
Common block and subprogram having the same name.
construct-name:
Use of a construct-name to label a control statement.
continuation:
More than 19 successive continuation lines.
cpp: Unix C preprocessor directives in the source code.
cray-pointer:
``Cray pointer'' syntax.
cycle-exit:
The CYCLE and EXIT statements.
d-comment:
Debugging comments starting with D in the source code.
dec-tab:
DEC Fortran style tab-formatted source code. This warning
will be given only if the -source=dec-tab setting is spec‐
ified to cause interpretation of tabs in this style.
do-enddo:
DO loop extensions: terminal statement label omitted, END
DO, and WHILE.
double-complex:
Double precision complex datatype.
format-dollarsign:
Dollar sign control code in FORMAT statements.
format-edit-descr:
Nonstandard edit descriptors in FORMAT statements.
function-noparen:
Function definition without parentheses.
implicit-none:
IMPLICIT NONE statement.
include:
INCLUDE statement.
inline-comment:
Inline comments starting with an exclamation point.
internal-list-io:
List-directed I/O to or from an internal file.
intrinsic:
Nonstandard intrinsic functions.
io-keywords
Nonstandard keywords used in I/O statements. These fall
into three groups. The first group includes keywords that
are accepted in Fortran 90:
ACTION PAD READWRITE
ADVANCE POSITION SIZE
DELIM READ WRITE
EOR
The second group comprises the following VMS Fortran key‐
words:
BLOCKSIZE EXTENDSIZE READONLY
BUFFERCOUNT INITIALSIZE RECORDSIZE
CARRIAGECONTROL MAXREC RECORDTYPE
DEFAULTFILE NAME (in OPEN) SHARED
DISP NOSPANBLOCK TYPE
DISPOSE ORGANIZATION
(The keyword NAME is standard only in the INQUIRE state‐
ment.) The third group consists of the following IBM/MVS
keyword:
NUM
This flag also controls a warning about use of
ACCESS='APPEND', which is accepted by some compilers. The
value of 'APPEND' is not valid for any I/O specifier in
standard Fortran 77, and in Fortran 90 'APPEND' should be
used as a value of the POSITION specifier, not ACCESS.
long-line:
Statements with meaningful code past 72 columns. This
warning is given only if the -columns setting has been
used to increase the statement field width.
long-name:
Identifiers over 6 characters long.
mixed-common:
Mixed character and noncharacter data in COMMON block.
mixed-expr:
Nonstandard type combinations in expressions, for example
DOUBLE PRECISION with COMPLEX, assigning hollerith to
integer, logical operations on integers.
name-dollarsign:
Dollar sign used as a character in identifiers.
name-underscore:
Underscore used as a character in identifiers.
namelist:
NAMELIST statement.
param-implicit-type:
Implicit typing of a parameter by the data type of the
value assigned. This warning can only occur if implicit
parameter typing has been turned on by the
-source=param-implicit-type option, or if the PARAMETER
statement is of the nonstandard form without parentheses.
If this option is turned on, then any instances where
implicit parameter typing occurs will be warned about. If
you want to be warned only in those instances where the
implicit data type differs from the default type, use
-portability=param-implicit-type instead. According to
the Fortran 77 standard, the data type of a parameter is
given by the same rules as for a variable, and if neces‐
sary a type conversion is done when the value is assigned.
param-intrinsic:
Intrinsic function or exponentiation by a real used to
define the value of a PARAMETER definition.
param-noparen:
PARAMETER statement without parentheses. The user should
be aware that the semantics of this form of the statement
differs from that of the standard form: in this form, the
parameter takes its data type from the value assigned,
rather than having its default data type based on the
first letter of the parameter name. (This form of the
PARAMETER statement was introduced by DEC before the For‐
tran 77 standard was defined, and should be avoided.)
pointer:
Fortran 90 standard pointer-related syntax, including
POINTER, TARGET and ALLOCATABLE type declarations, ALLO‐
CATE, DEALLOCATE, and NULLIFY statements, and pointer
assignment using =>.
quad-constant:
Quad precision real constants, e.g. of the form 1.23Q4.
quotemark:
Strings delimited by quote marks rather than apostrophes.
relops:
Relational (comparison) operators composed of punctuation,
namely: < <= == /= > >=.
semicolon:
Semicolon used as statement separator.
statement-order:
Statements out of the sequence mandated by the Standard.
The allowed sequence is illustrated in Table 1 in the sec‐
tion on Interpreting the Output.
typeless-constant:
Typeless constants, for example Z'19AF'.
type-size:
Type declarations specifying a size, for example REAL*8.
variable-format:
Variable repeat specification or field size in FORMAT.
These are of the form < expr >.
vms-io:
Obsolete. Now has the same meaning as the io-keywords
keyword.
See also: -f90, -f95, -portability, -pretty, -style, -wordsize.
-f90=list
This setting provides detailed control over the warnings about
supported extensions to the Fortran 77 Standard that were not
adopted as part of the Fortran 90 Standard. Note that ftnchek
does not support the full Fortran 90 language. However, it does
support some common extensions to Fortran 77 that were prevalent
before Fortran 90 was defined. Some of these extensions became
part of the Fortran 90 Standard, but others did not. The -f90
setting warns only about the latter. That is, this flag covers
things that are neither legal Fortran 77 nor legal Fortran 90.
Therefore, the warnings controlled by this flag are basically a
subset of the warnings controlled by -f77. There are a few
cases, described below, where the circumstances in which the
warning is given are slightly different for the two flags.
The list consists of keywords separated by commas or colons.
There are three special keywords: all to turn on all the warn‐
ings about nonstandard extensions, none to turn them all off,
and help to print the list of all the keywords with a brief
explanation of each. If list is omitted, -f90 is equivalent to
-f90=all, and -nof90 is equivalent to -f90=none.
The following keywords have identical meanings for -f90 as for
-f77. The reader is referred to the explanations under -f77.
accept-type double-complex param-noparen
backslash format-dollarsign cray-pointer
byte format-edit-descr quad-constant
cpp function-noparen type-size
d-comment name-dollarsign variable-format
dec-tab param-implicit-type vms-io
The keywords which differ somewhat from the corresponding -f77
keywords are as follows.
continuation:
The limit on the number of continuation lines for a state‐
ment in fixed source form is the same, namely 19, in For‐
tran 90 as in Fortran 77. For free source form the limit
is 39 continuation lines, and a line containing a continu‐
ation mark cannot be otherwise empty or contain only a
comment.
intrinsic:
This is the same as for -f77 except for the intrinsic
functions defined in MIL-STD 1753, which are all included
in Fortran 90, and so are not warned about. (See -intrin‐
sic for a list.)
io-keywords:
This is the same as for -f77 except that no warnings are
given for the I/O keywords that are standard in Fortran
90.
long-line:
Although the Fortran 90 Standard allows lines longer than
72 characters in free source form, this restriction still
applies to fixed source form. In free source form the
line length limit is 132 characters, and unlike fixed
form, ftnchek does not allow this limit to be increased.
mixed-expr:
This is the same as for -f77 except for expressions mixing
extended precision real with complex data types, which are
permitted in Fortran 90.
statement-order:
This is similar to the corresponding -f77 warning, but
applies the somewhat looser restrictions on statement
order of the Fortran 90 Standard. In particular, Fortran
90 allows DATA statements and statement-function defini‐
tions to be intermixed with specification statements.
typeless-constant:
In Fortran 90, binary, octal, and hexadecimal constants of
the form B'ddd', O'ddd', and Z'ddd', respectively, are
permitted. Here 'ddd' represents a string of digits.
ftnchek recognizes these forms, as well as a variant of
the form X'ddd' for a hexadecimal constant, and other
variants in which the base indicator B, O, Z, or X follows
the digit string. These variants were not adopted in For‐
tran 90, so only they are warned about when this flag is
turned on.
See also: -f77, -f95, -portability, -pretty, -style, -wordsize.
-f95=list
This setting provides detailed control over warnings about stan‐
dard Fortran 77 features that were deleted from the Fortran 95
Standard. Unlike the -f77 and -f90 settings, these warnings
apply to syntax which is legal Fortran 77. However, since these
features have been deleted from the Standard, it is possible
that programs containing them will be unacceptable to some newer
compilers.
The list consists of keywords separated by commas or colons.
There are three special keywords: all to turn on all the warn‐
ings about nonstandard extensions, none to turn them all off,
and help to print the list of all the keywords with a brief
explanation of each. If list is omitted, -f95 is equivalent to
-f95=all, and -nof95 is equivalent to -f95=none. The warning
keywords with their meanings are as follows.
real-do:
A DO variable of any real numeric type.
pause:
The PAUSE statement.
assign:
The ASSIGN statement, assigned GOTO, or assigned format.
h-edit:
The H edit descriptor in a format.
There is one other Fortran 77 syntax feature that was deleted in
Fortran 95, namely branching to an ENDIF from outside the IF
block. However, ftnchek is unable to analyze program flow, and
so it does not provide a warning for this.
See also: -f77, -f90, -portability, -pretty, -style, -wordsize.
-help
Prints a list of all the command-line options with a short
description of each along with its default value. This command
is identical in function to the ``?'' argument, and is provided
as a convenience for those systems in which the question mark
has special meaning to the command interpreter. Default = no.
The help listing also prints the version number and patch level
of ftnchek and a copyright notice.
Note: the ``default'' values printed in square brackets in the
help listing are, strictly speaking, not the built-in defaults
but the current values after any environment options and any
command-line options preceding the -help option have been pro‐
cessed.
See also: -novice, -version, and help option of all settings
that take a list of keywords.
-identifier-chars=list
Define non-alphanumeric characters that may be used in identi‐
fiers. By default, ftnchek only accepts the dollar sign and
underscore as non-alphanumeric characters in identifier names.
The characters in the list replace whatever set of accepted non-
alphanumeric characters was previously in effect. Thus, if dol‐
lar sign or underscore are not included in the list, they lose
their status as acceptable characters.
This option is provided to enable ftnchek to handle source files
containing non-standard identifer names that may be needed, for
example, to access certain operating system services. See the
section on Limitations and Extensions for the treatment of iden‐
tifiers containing these characters in implicit typing.
Using -noidentifer-chars turns off acceptance of non-alphanu‐
meric characters entirely.
See also: -source.
-include=path
Specifies a directory to be searched for files specified by
INCLUDE statements. Unlike other command-line options, this
setting is cumulative; that is, if it is given more than once on
the command line, all the directories so specified are placed on
a list that will be searched in the same order as they are
given. The order in which ftnchek searches for a file to be
included is: the current directory; the directory specified by
environment variable FTNCHEK_INCLUDE if any; the directories
specified by any -include options; the directory specified by
environment variable INCLUDE; and finally in a standard system-
wide directory (/usr/include for UNIX, SYS$LIBRARY for VMS, and
\include for MSDOS).
See also: -f77, -source.
-intrinsic=list
Controls whether ftnchek recognizes certain nonstandard intrin‐
sic functions as intrinsic. The list consists of keywords sepa‐
rated by commas or colons. Some of the keywords control whether
to recognize certain groups of functions, and other keywords
control the expected syntax for invoking some nonstandard
intrinsics. Include a keyword to turn on recognition of the
corresponding set of intrinsics or to allow the corresponding
syntax. Include a keyword prefixed by no- to turn off that
recognition.
There are three special keywords: all turns on recognition of
all the nonstandard intrinsics (listed below) and accepts either
syntax for those that have variations. Use none to turn off
recognition of all nonstandard intrinsics except those noted
below. Use help to print the list of all the keywords with a
brief explanation of each. If list is omitted, -intrinsic is
equivalent to -intrinsic=all, and -nointrinsic is equivalent to
-intrinsic=none.
The nonstandard intrinsic functions needed to support the non‐
standard extended precision data types (double complex and quad
precision) are always recognized. The intrinsics for the double
complex data type are:
CDABS CDSQRT DREAL ZLOG
CDCOS DCMPLX IMAG ZSIN
CDEXP DCONJG ZABS ZSQRT
CDLOG DIMAG ZEXP ZCOS
CDSIN
The intrinsics for the quad precision and quad complex types
are:
CQABS QARCOS QEXT QNINT
CQCOS QARSIN QEXTD QPROD
CQEXP QATAN QFLOAT QREAL
CQLOG QATAN2 QIMAG QSIGN
CQSIN QCMPLX QINT QSIN
CQSQRT QCONJG QLOG QSINH
DBLEQ QCOS QLOG10 QSQRT
IQINT QCOSH QMAX1 QTAN
IQNINT QDIM QMIN1 QTANH
QABS QEXP QMOD SNGLQ
The keywords controlling recognition of other nonstandard
intrinsic functions are as follows:
extra:
recognize the following commonly available nonstandard
intrinsics (all except EXIT and LOC are defined in MIL-STD
1753):
BTEST IBCLR IEOR ISHFTC
EXIT IBITS IOR LOC
IAND IBSET ISHFT NOT
unix: recognize these common Unix-specific intrinsic functions:
ABORT GMTIME LTIME SRAND
AND IARGC OR SYSTEM
GETARG IRAND RAND TIME
GETENV LSHIFT RSHIFT XOR
vms: recognize these common VMS-specific intrinsic functions:
DATE IDATE SECNDS TIME
ERRSNS RAN SIZEOF
iargc-no-argument:
specify that IARGC may be invoked with no arguments.
iargc-one-argument:
specify that IARGC may be invoked with one argument.
rand-no-argument:
specify that RAND and IRAND may be invoked with no argu‐
ments.
rand-one-argument:
specify that RAND and IRAND may be invoked with one argu‐
ment.
The no-argument and one-argument keywords work as follows: turn‐
ing the option on causes ftnchek to accept the corresponding
syntax for invocation of the function, without excluding the
possibility of the alternative syntax. Turning the option off
causes the corresponding syntax not to be accepted. If both
options are turned on at once (the default), then either syntax
is accepted. Turning both options off at once would not be
meaningful. These options have no effect if recognition of Unix
intrinsics has been turned off.
Note that this setting does not control whether non-standard
warnings are issued about these functions. It controls whether
the functions are assumed to be intrinsic or not, which deter‐
mines how their usage is checked. When functions in any of
these sets are included, their invocations will be checked
according to the rules for the intrinsic functions; otherwise
they will be checked as normal (user-written) external func‐
tions. The non-standard warnings are controlled by the
-f77=intrinsic option.
The default value of this setting is equivalent to -intrin‐
sic=all followed by -intrinsic=no-vms for the Unix version,
-intrinsic=no-unix for the VMS version, and -intrin‐
sic=no-unix,no-vms for other versions.
Note: In versions of ftnchek prior to 2.10, the -intrinsic flag
took a numeric argument instead of a list of options. For the
sake of users who may have written scripts invoking ftnchek in
this way, the numeric form is still accepted. The numeric form
of the setting consists of three digits. The ones digit selects
the set of intrinsic functions to be supported. The digit 0
selects only Fortran 77 standard intrinsics plus those needed to
support the nonstandard extended precision data types. The
digit 1 is equivalent to extra, 2 is equivalent to extra,unix,
and 3 is equivalent to extra,vms. The tens digit of this set‐
ting controls the syntax of the RAND intrinsic function, and the
hundreds digit controls the syntax of the IARGC function. For
these digits, specify 0 to require invocation with no argument,
1 to require one argument, and 2 to allow either form.
See also: -f77.
-library
This switch is used when a number of subprograms are contained
in a file, but not all of them are used by the application.
Normally, ftnchek warns you if any subprograms are defined but
never used. This switch will suppress these warnings. Default
= no.
This switch also controls which subprogram calls and COMMON
block declarations are checked. If a file is read with the
-library flag in effect, the subprogram calls and COMMON decla‐
rations contained in a routine in that file will be checked only
if that routine is in the main program's call tree. On the
other hand, if the -library switch is turned off, then ftnchek
checks the calls of every routine by every other routine,
regardless of whether those routines could ever actually be
invoked at run time, and likewise all COMMON block declarations
are compared for agreement.
The difference between this switch and the -usage=no-ext-unused
option for subprograms is that the latter suppresses only the
warning about routines being declared but not used. The
-library switch goes further and excludes unused routines pro‐
cessed while it is in effect from all cross-checking of argu‐
ments and COMMON block declarations as well.
(If there is no main program anywhere in the set of files that
ftnchek has read, so that there is no call tree, then ftnchek
will look for any non-library routines that are not called by
any other routine, and use these as substitutes for the main
program in constructing the call tree and deciding what to
check. If no such top-level non-library routines are found,
then all inter-module calls and all COMMON declarations will be
checked.)
See also: -arguments, -calltree, -common, -extern, -usage.
-list
Specifies that a listing of the Fortran program is to be printed
out with line numbers. If ftnchek detects an error, the error
message follows the program line with a caret ( ^ ) specifying
the location of the error. If no source listing was requested,
ftnchek will still print out any line containing an error, to
aid the user in determining where the error occurred. Default =
no.
See also: -output, \fB-symtab, fB-quiet.
-makedcls=list
Prepare a neatly-formatted file of declarations of variables,
common blocks, and namelist lists, for possible merging into the
source code. The declarations are stored in a file of the same
name as the source code, but with the extension changed to .dcl.
If no declarations are written to the file, it is deleted to
reduce clutter from empty files.
If input comes from standard input, instead of a named file,
then declarations are written to standard output.
Variables are declared in alphabetical order within each decla‐
ration class and type, with integer variables first, because of
their later possible use in array dimensions.
PARAMETER statements are an exception to the alphabetical order
rule, because the Fortran 77 Standard requires that the expres‐
sions defining parameter values refer only to constants and
already-defined parameter names. This forces the original
source file order of such statements to be preserved in the dec‐
laration files.
Explicit declaration of all variables is considered good modern
programming practice. By using compiler options to reject unde‐
clared variables, misspelled variable names (or names extending
past column 72) can be caught at compile time. Explicit decla‐
rations also greatly facilitate changing floating-point preci‐
sion with filters such as dtoq(1L), dtos(1L), fd2s(1L),
fs2d(1L), qtod(1L), and stod(1L). These programs are capable of
changing types of explicit floating-point type declarations,
intrinsic functions, and constants, but because they do not
carry out rigorous lexical and grammatical analysis of the For‐
tran source code, they cannot provide modified type declarations
for undeclared variables. Default setting = 0, turn-on = 1.
Various options for the form of the declarations file are con‐
trolled by the list, which consists of keywords separated by
commas or colons. There are three special keywords: all to turn
on all the options, none to turn them all off, and help to print
the list of all the keywords with a brief explanation of each.
If list is omitted, -makedcls is equivalent to -makedcls=decla‐
rations (i.e. produce the declarations file using the default
options), and -nomakedcls is equivalent to -makedcls=none.
For compatibility with previous versions of ftnchek, a numeric
form of this setting is also accepted: the list is replaced by
a number which is the sum of the numbers in parentheses beside
the keywords in the following list. The warning keywords with
their meanings are as follows:
declarations (1):
Write a declaration file. (This is implied by any of the
other options, and can be omitted if any other options are
given.)
undeclared-only (2):
By default, all variables are included in the declaration
file. With this option, include only undeclared vari‐
ables. This setting is useful if you want to check for
undeclared variables, since Fortran source files with all
variables properly declared will not result in a .dcl
file. With this option, common blocks and namelist lists
will not be included in the declaration file, since by
their nature they cannot be undeclared.
compact (4):
The declarations are normally prettyprinted to line up
neatly in common columns, as in the declaration files out‐
put by the Extended PFORT Verifier, pfort(1L). This
option value selects instead compact output, without col‐
umn alignment.
use-continuation-lines (8):
Causes continuation lines to be used where permissible.
The default is to begin a new declaration on each line.
This option is appropriate to use together with compact.
keywords-lowercase (16):
Output Fortran keywords in lowercase, instead of the
default uppercase.
vars-and-consts-lowercase (32):
Output variables and constants in lowercase, instead of
the default uppercase. Character string constants are
not affected by this option.
exclude-sftran3 (64):
Omit declarations of internal integer variables produced
by the SFTRAN3 preprocessor, xsf3(1L), as part of the
translation of structured Fortran statements to ordinary
Fortran. These variables have six-character names of the
form NPRddd, NXdddd, N2dddd, and N3dddd, where d is a dec‐
imal digit. Because they are invisible in the SFTRAN3
source code, and will change if the SFTRAN3 code is modi‐
fied, such variables should not be explicitly declared.
Instead, they should just assume the default Fortran INTE‐
GER data type based on their initial letter, N.
asterisk-comment (128):
Use an asterisk as the comment character; the default is
otherwise 'C'.
comment-char-lowercase (256):
Use 'c' instead of 'C' or '*' as the comment character.
suppress-array-dimensions (512):
Suppress dimensioning of arrays in the generated declara‐
tions. This option is for use with code lacking type dec‐
larations, to allow the declaration files to be inserted
without change into the code. Since the code will have
dimension statements already, dimensioning the array vari‐
ables in the type statements of the declaration file is
redundant. This option should be used only in conjunction
with option 2 = undeclared-only because otherwise any
arrays that were dimensioned in a type statement will lose
their dimensioning.
free-form (1024):
Produce declarations in free source form. This mode is
automatically used if the input source is free form. Use
this option to produce declarations in free form even if
the input is in fixed form. Free form declarations are
indented only 2 columns instead of 6, use the exclamation
mark as the comment character, and indicate continuation
lines by an ampersand at the end of the line to be contin‐
ued.
The declaration files contain distinctive comments that mark the
start and end of declarations for each program unit, to facili‐
tate using text editor macros for merging the declarations back
into the source code.
The ftnchek distribution includes a program, dcl2inc, which pro‐
cesses declaration files to produce files containing declara‐
tions of all COMMON blocks, in a form suitable for use as
INCLUDE files. See the dcl2inc(1L) man page for the details of
its use.
See also: -mkhtml.
-mkhtml=list
Produce HTML documentation from source. Creates individual HTML
files from ftnchek analysis and code comments. All comments
immediately preceding and following the function or subroutine
definition are captured to the HTML file. No reformatting of
source comments is performed other than stripping of FORTRAN
comment characters. In addition, the HTML file lists the local
variables declared, common block variables used, functions and
subroutines called, I/O unit usage, and other information about
each subprogram. Usually you will also want to specify
-call=tree to create the root HTML file CallTree.html. (Perhaps
this file should be named index.html.)
Various options for the form of the HTML files are controlled by
the list, which consists of keywords separated by commas or
colons. There are three special keywords: all to turn on all
the options, none to turn them all off, and help to print the
list of all the keywords with a brief explanation of each. If
list is omitted, -mkhtml is equivalent to -mkhtml=documents
(i.e. produce the HTML document files using the default
options), and -nomkhtmls is equivalent to -mkhtml=none.
For the sake of simplicity, the options for -mkhtml are the same
as those for -makedcls except for those that are inapplicable.
Likewise, a numeric form of this setting can be used, formed as
the sum of the numbers in parentheses in the list below. The
warning keywords with their meanings are as follows:
documents (1):
Create the HTML documents. (This is implied by any of the
other options, and can be omitted if any other options are
given.)
compact (4):
The declarations are normally prettyprinted to line up
neatly in common columns. This option value selects
instead compact output, without column alignment.
use-continuation-lines (8):
Causes continuation lines to be used instead of beginning
a new declaration on each line. This option is appropri‐
ate to use together with compact.
keywords-lowercase (16):
Output Fortran keywords in lowercase, instead of the
default uppercase.
vars-and-consts-lowercase (32):
Output variables and constants in lowercase, instead of
the default uppercase. Character string constants are
not affected by this option.
exclude-sftran3 (64):
Omit declarations of internal integer variables produced
by the SFTRAN3 preprocessor, xsf3(1L). (See -makedcls for
discussion.)
suppress-array-dimensions (512):
Suppress dimensioning of arrays in the generated declara‐
tions. This is normally undesirable, but is available if
for some reason you do not want the array dimensions to
appear in the HTML.
free-form (1024):
Produce variable declarations in free source form. This
mode is automatically used if the input source is free
form. This mainly affects the form of continuation lines
if they are used.
See also: -calltree, -makedcls.
-novice
This flag is intended to provide more helpful output for begin‐
ners. It has two effects:
(a) provides an extra message to the effect that a function that
is used but not defined anywhere might be an array which the
user forgot to declare in a DIMENSION statement (since the
syntax of an array reference is the same as that of a func‐
tion reference).
(b) modifies the form of the error messages and warnings. If
the flag is turned off by -nonovice, these messages are
printed in a style more resembling UNIX lint.
Default = yes.
-output=filename
This setting is provided for convenience on systems which do not
allow easy redirection of output from programs. When this set‐
ting is given, the output which normally appears on the screen
will be sent instead to the named file. Note, however, that
operational errors of ftnchek itself (e.g. out of space or can‐
not open file) will still be sent to the screen. The extension
for the filename is optional, and if no extension is given, the
extension .lis will be used.
-pointersize=num
Specifies the size of a ``Cray pointer'' variable to be num
bytes. Default = turn-on = 4 bytes.
The pointer size is used to inform precision mismatch warnings
involving pointer variables, for example when a pointer is
assigned a value from an allocation routine, or passed as a sub‐
program parameter.
See also: -f77, -portability, -truncation, -wordsize.
-portability=list
ftnchek will give warnings for a variety of non-portable usages.
Examples include the use of tabs except in comments or inside
strings, the use of Hollerith constants, and the equivalencing
of variables of different data types. This option does not pro‐
duce warnings for supported extensions to the Fortran 77 Stan‐
dard, which may also cause portability problems. To catch
those, use the -f77 setting. By default, all warnings are
turned off.
This setting provides detailed control over the warnings about
possible portability problems. The list consists of keywords
separated by commas or colons. There are three special key‐
words: all to turn on all the warnings about nonportable usages,
none to turn them all off, and help to print the list of all the
keywords with a brief explanation of each. If list is omitted,
-portability is equivalent to -portability=all, and -noportabil‐
ity is equivalent to -portability=none. The warning keywords
with their meanings are as follows:
backslash:
Backslash character in strings. Since some compilers
treat the backslash as an escape character, its presence
can cause problems even though it is used in a standard-
conforming way.
common-alignment:
COMMON block variables not in descending order of storage
size. Some compilers require this ordering because of
storage alignment requirements.
hollerith:
Hollerith constants (other than within FORMAT specifica‐
tions). The Hollerith data type is a feature of Fortran
IV that has been deleted in the Fortran 77 standard. It
is superseded by the character data type. Storing Hol‐
lerith data in variables of a numeric or logical data type
is nonportable due to differing word sizes.
long-string:
String constants, variables, or expressions over 255 chars
long.
mixed-equivalence:
Variables of different data types equivalenced.
mixed-size:
Variables declared with default precision used with vari‐
ables given explicit precision, in expressions, assign‐
ments, or as arguments. For example, if a variable
declared as REAL*8 is treated as equivalent to DOUBLE PRE‐
CISION.
real-do:
Non-integer DO loop index and bounds. These can cause a
program's results to depend on the hardware characteris‐
tics of the particular computer used.
param-implicit-type:
Implicit typing of a parameter by the data type of the
value assigned, if it differs from the default type. This
warning can only occur if implicit parameter typing has
been turned on by the -source=param-implicit-type option,
or if the PARAMETER statement is of the nonstandard form
without parentheses. If this option is turned on, then
any instances where implicit parameter typing occurs and
where the implicit type is different from the default type
based on the first letter of the parameter name, will be
warned about. Implicit parameter typing can change the
semantics of statements where the parameter is used, caus‐
ing portability problems.
tab: Tabs in source code. Tabs are interpreted differently by
different compilers. This warning will be given only
once, at the end of the file.
See also: -f77, -f90, -f95, -pretty, -style, -wordsize.
-pretty=list
Controls certain messages related to the appearance of the
source code. These warn about things that might make a program
less readable or be deceptive to the reader. By default, all
warnings are turned on.
This setting provides detailed control over the warnings about
appearance. The list consists of keywords separated by commas
or colons. Since all warnings are on by default, include a key‐
word prefixed by no- to turn off a particular warning. There
are three special keywords: all to turn on all the warnings
about misleading appearances, none to turn them all off, and
help to print the list of all the keywords with a brief explana‐
tion of each. If list is omitted, -pretty is equivalent to
-pretty=all, and -nopretty is equivalent to -pretty=none. The
warning keywords with their meanings are as follows:
alternate-return:
A RETURN statement has a constant specifying an alternate
return point that is not between 0 and the number of dummy
arguments that are labels. This is legal, and has the
same effect as a RETURN with no alternate return expres‐
sion, but suggests that the programmer intended to use an
alternate return label that is not provided.
embedded-space:
Space embedded in variable names or in multi-character
operators such as **.
continuation:
Continuation mark following a comment line.
long-line:
Lines (except comments) over 72 columns in width (beyond
72 is normally ignored by compiler).
missing-space:
Lack of space between variable and a preceding keyword.
multiple-common:
COMMON block declared in multiple statements. No warning
is given if the statements are consecutive except for com‐
ment lines.
multiple-namelist:
NAMELIST declared in multiple statements. No warning is
given if the statements are consecutive except for comment
lines.
parentheses:
Parentheses around a variable by itself. As a subprogram
argument, this makes the argument an expression, not modi‐
fiable by the subprogram.
Note that in free source form, extra space and missing space are
forbidden by the Fortran 90 Standard, and are not mere style
violations. In this case the warnings are replaced by syntax
error messages, and can be turned off only by using -nocheck.
See also: -f77, -portability, -style.
-project=list
ftnchek will create a project file from each source file that is
input while this option is turned on. The project file will be
given the same name as the input file, but with the extension .f
or .for replaced by .prj. (If input is from standard input, the
project file is named ftnchek.prj.) Default = none.
The list consists of keywords separated by commas or colons.
There are three special keywords: all to turn on all the
options, none to turn them all off, and help to print the list
of all the keywords with a brief explanation of each. If list
is omitted, -project is equivalent to -project=all, and -nopro‐
ject is equivalent to -project=none. The keywords with their
meanings are as follows:
create:
Produce a project file. The default is not to produce a
project file. If this option is not turned on, the other
options have no effect.
trim-calls:
Trim the amount of information stored in the project file
about subprogram declarations and calls. This is the
default. Turn this option off only in rare situations.
(See discussion below.) The amount of trimming varies
depending on the -library flag. More information is
trimmed if that flag is turned on.
trim-common:
Trim the number of common block declarations stored in the
project file. This is the default. Turn this option off
only in rare situations. (See discussion below.) This
option has no effect if the -library flag is turned off:
when not in library mode, no trimming of common block dec‐
larations is done regardless of this option.
A project file contains a summary of information from the source
file, for use in checking agreement among FUNCTION, SUBROUTINE,
and COMMON usages in other files. It allows incremental check‐
ing, which saves time whenever you have a large set of files
containing shared subroutines, most of which seldom change. You
can run ftnchek once on each file with the -project flag set,
creating the project files. Usually you would also set the
-library and -noextern flags at this time, to suppress messages
relating to consistency with other files. Only error messages
pertaining to each file by itself will be printed at this time.
Thereafter, run ftnchek without these flags on all the project
files together, to check consistency among the different files.
All messages internal to the individual files will now be omit‐
ted. Only when a file is altered will a new project file need
to be made for it.
Naturally, when the -project option is turned on, ftnchek will
not read project files as input.
Ordinarily, the trim options should be left on when you intend
to create project files for future input to ftnchek. Since
trimming is on by default, this means that simply giving the
command -project with no option list is the recommended mode.
The trim options are provided only as a convenience for those
who want to make use of project files for purposes other than
checking the program with ftnchek. To use project files for
their intended purpose, the trim options should not be turned
off.
Project files contain only information needed for checking
agreement between files. This means that a project file is of
no use if all modules of the complete program are contained in a
single file.
A more detailed discussion is given in the section on Using
Project Files.
-pure
Assume functions are ``pure'', i.e., they will not have side
effects by modifying their arguments or variables in a COMMON
block. When this flag is in effect, ftnchek will base its
determination of set and used status of the actual arguments on
the assumption that arguments passed to a function are not
altered. It will also issue a warning if a function is found to
modify any of its arguments or any COMMON variables. Default =
yes.
When this flag is turned off, actual arguments passed to func‐
tions will be handled the same way as actual arguments passed to
subroutines. This means that ftnchek will assume that arguments
may be modified by the functions. No warnings will be given if
a function is found to have side effects. Because stricter
checking is possible if functions are assumed to be pure, you
should turn this flag off only if your program actually uses
functions with side effects.
-quiet
This option reduces the amount of output relating to normal
operation, so that error messages are more apparent. This
option is provided for the convenience of users who are checking
large suites of files. The eliminated output includes the names
of project files, and the message reporting that no syntax
errors were found. It also eliminates some blank lines that are
ordinarily included for clarity. (Some of this output is turned
back on by the -list and -symtab options.) Default = no.
Note: the way to remember the difference between the -quiet and
-brief is that -quiet doesn't suppress any warning-related
information, whereas -brief does.
See also: -brief.
-reference
Specifies that a who-calls-who table be printed. This table
lists each subprogram followed by a list of the routines it
calls. This switch is equivalent to -calltree=reference.
Default = no.
The reference list omits routines called by unused library mod‐
ules. Thus it contains the same information as for the call-
tree format, namely the hierarchy of subprogram calls, but
printed in a different way. This prints out a breadth-first
traversal of the call tree whereas -calltree=tree prints out a
depth-first traversal.
See also: -calltree, -crossref, -library, -sort, -symtab, -vcg.
-resources
Prints the amount of resources used by ftnchek in processing the
program. This listing may be useful in analyzing the size and
complexity of a program. It can also help in choosing larger
sizes for ftnchek's internal tables if they are too small to
analyze a particular program. Default = no.
In this listing, the term ``chunk size'' is the size of the
blocks of memory allocated to store the item in question, in
units of the size of one item, not necessarily in bytes. When
the initially allocated space is filled up, more memory is allo‐
cated in chunks of this size. The following is an explanation
of the items printed:
Source lines processed:
Total number of lines of code, with separate totals for
statement lines and comment lines. Comment lines include
lines with 'C' or '*' in column 1 as well as blank lines and
lines containing only an inline comment. Statement lines
are all other lines, including lines that have an inline
comment following some code. Continuation lines are counted
as separate lines. Lines in include files are counted each
time the file is included.
Total executable statements:
Number of statements in the program, other than specifica‐
tion, data, statement-function, FORMAT, ENTRY, and END
statements.
Total number of modules:
A module is any external subprogram, including the main pro‐
gram, subroutines, functions, and block data units. This
count is of modules defined within the source, not modules
referenced. Statement functions are not included. A sub‐
program with multiple entry points is only counted once.
Total statement labels defined
Number of labels attached to statements (often called state‐
ment numbers). The total label count for the entire program
is given, as well as the maximum number in any single sub‐
program.
Max identifier name chars:
Number of characters used for storing identifier names. An
identifier is a variable, subprogram, or common block name.
Local names are those of local variables in a subprogram,
whereas global names refer to subprogram and common block
names, as well as dummy argument names and common variable
names. Actual argument text (up to 15 characters for each
argument) is also included here. The space used for local
names is not recovered at the end of each module, so this
number, like global space, grows until the whole program is
analyzed. Unfortunately, this figure may include some text
stored more than once, although a heuristic is used that
will avoid duplicates in many cases.
Max token text chars:
A token is the smallest syntactic unit of the FORTRAN lan‐
guage above the level of individual characters. For instance
a token can be a variable name, a numerical constant, a
quoted text string, or a punctuation character. Token text
is stored while a module is being processed. For technical
reasons, single-character tokens are not included in this
total. Items that are not represented in the symbol table
may be duplicated. The space for token text is recovered at
the end of each module, so this figure represents the maxi‐
mum for any one module.
Max local symbols:
This is the largest number of entries in the local symbol
table for any module. Local symbol table entries include
all variables and parameters, common block names, statement
functions, external subprograms and intrinsic functions ref‐
erenced by the module. Literal constants are not stored in
the local symbol table.
Max global symbols:
This is the number of entries in the global symbol table at
the end of processing. Global symbol table entries include
external subprogram and common block names. Intrinsic func‐
tions and statement functions are not included.
Max number of tokenlists:
A token list is a sequence of tokens representing the actual
or dummy argument list of a subprogram, or the list of vari‐
ables in a common block or namelist. Therefore this number
represents the largest sum of COMMON, CALL, NAMELIST and
ENTRY statements and function invocations for any one mod‐
ule. The space is recovered at the end of each module.
Max token list/tree space:
This is the largest number of tokens in all the token lists
and token trees of any one module. A token tree is formed
when analyzing an expression: each operand is a leaf of the
tree, and the operators are the nodes. Therefore this num‐
ber is a measure of the maximum complexity of an individual
module. For instance a module with many long arithmetic
expressions will have a high number. Note that unlike token
text described above, the number of tokens is independent of
the length of the variable names or literal constants in the
expressions.
Number of subprogram invocations:
This is the sum over all modules of the number of CALL
statements and function invocations (except intrinsic func‐
tions and statement functions).
Number of common block decls:
This is the sum over all modules of the number of common
block declarations. That is, each declaration of a block in
a different module is counted separately. (The standard
allows multiple declarations of a block within the same mod‐
ule; these are counted as only one declaration since they
are equivalent to a single long declaration.)
Number of array dim & param ptrs:
This is the sum over all modules of the number of array
dimension and parameter definition text strings saved for
use by the -makedcls option. The length of the text strings
is not counted. Each dimension of a multidimensional array
is counted separately.
These numbers are obviously not the same when project files are
used in place of the original source code. Even the numbers for
global entities may be different, since some redundant informa‐
tion is eliminated in project files.
-sixchar
One of the goals of the ftnchek program is to help users to
write portable Fortran programs. One potential source of non‐
portability is the use of variable names that are longer than
six characters. Some compilers just ignore the extra charac‐
ters. This behavior could potentially lead to two different
variables being considered as the same. For instance, variables
named AVERAGECOST and AVERAGEPRICE are the same in the first six
characters. If you wish to catch such possible conflicts, use
this flag. Default = no.
Use the -f77=long-names if you want to list all variables longer
than six characters, not just those pairs that are the same in
the first six.
See also: -f77, -portability.
-sort
Specifies that a sorted list of all modules used in the program
be printed. This list is in ``prerequisite'' order, i.e. each
module is printed only after all the modules from which it is
called have been printed. This is also called a ``topological
sort'' of the call tree. Each module is listed only once. Rou‐
tines that are not in the call tree of the main program are
omitted. If there are any cycles in the call graph (illegal in
standard Fortran) they will be detected and diagnosed. Default
= no.
See also: -calltree, -crossref, -reference, -symtab, -vcg.
-source=list
This setting controls certain options about the form of the For‐
tran source code. The list consists of keywords separated by
commas or colons. There are three special keywords: all to turn
on all the options, none to turn them all off, and help to print
the list of all the keywords with a brief explanation of each.
If list is omitted, -source is equivalent to -source=all, and
-nosource is equivalent to -source=none.
For compatibility with previous versions of ftnchek, a numeric
form of this setting is also accepted: the list is replaced by
a number which is the sum of the numbers in parentheses beside
the keywords in the following list. (The fixed and free options
do not have numeric values.) The warning keywords with their
meanings are as follows:
fixed:
Interpret the source as fixed form (with supported exten‐
sions such as exclamation mark for comments). Statements
must be in columns 7 to 72 (unless the -cols setting has
been used to change this), and blanks are not significant
outside character context (but warned about under the
-pretty option). This is the default mode unless the
source file extension is .f90 or .F90. this option cannot
be given together with -source=free.
free: Interpret the source as free form. Statements may be any‐
where in columns 1 to 132, comments can only begin with an
exclamation mark, and blanks are required in some places
such as between identifiers and keywords. This is the
default mode if the source file extension is .f90 or .F90.
This option cannot be given together with -source=fixed or
-source=dec-tab
dec-tab (1):
Accept DEC-style tab-formatted source. A line beginning
with an initial tab will be treated as a new statement
line unless the character after the tab is a nonzero
digit, in which case it is treated as a continuation line.
The next column after the tab or continuation mark is
taken as column 7. A warning will be given in the case
where the line is a continuation, if -f77=dec-tab is in
effect.
vms-include (2):
Accept VMS-style INCLUDE statements. These follow the
normal syntax, but with the following additional features:
(1) the file extension, if not given, defaults to the same
as a normal source file extension; and (2) the option
/LIST or /NOLIST can be appended to the include-file name,
to control listing of its contents.
unix-backslash (4):
Handle UNIX-style backslash escapes in character strings.
The escape sequence following the backslash will be evalu‐
ated according to the ANSI standard for strings in C: up
to three digits signify an octal value, an x signifies the
start of a hexadecimal constant, any of the letters a b f
n r t signify special control codes, and any other charac‐
ter (including newline) signifies the character itself.
When this source code option is in effect, a warning will
be given if the -f77=backslash setting is specified.
The default behavior is to treat the backslash like any
other normal character, but a warning about portability
will be generated if the -portability flag is set.
Because of the fact that some compilers treat the back‐
slash in a nonstandard way, it is possible for standard-
conforming programs to be non-portable if they use the
backslash character in strings.
Since ftnchek does not do much with the interpreted
string, it is seldom necessary to use this option. It is
needed in order to avoid spurious warnings only if (a) the
program being checked uses backslash to embed an apostro‐
phe or quote mark in a string instead of using the stan‐
dard mechanism of doubling the delimiter; (b) the back‐
slash is used to escape the end-of-line in order to con‐
tinue a string across multiple source lines; or (c) a
PARAMETER definition uses an intrinsic string function
such as LEN with such a string as argument, and that value
is later used to define array dimensions, etc.
param-implicit-type (8):
Implicit typing of a parameter by the data type of the
value assigned. Some non-standard compilers may allow the
data type of the value to override the Fortran 77 default
type of a parameter that is based on the first letter of
the parameter name. This option only applies to PARAMETER
statements of the standard form which has parentheses. A
parameter that has been explicitly declared in a type
statement prior to the PARAMETER statement is not affected
by this option. A warning will be given under the
-f77=param-implicit-type or -portabil‐
ity=param-implicit-type option.
Note that this implicit typing is treated as equivalent to
an explicit type declaration for the parameter. There‐
fore, if you use -makedcls=undeclared-only to generate
declarations only of undeclared variables, these parame‐
ters will not be included.
dec-param-standard-type (16):
Follow the Fortran 77 rule for data typing of DEC Fortran
style parameters. These are declared using a nonstandard
form of the PARAMETER statement which lacks parentheses.
According to DEC Fortran, parameters defined by this form
of the statement have their data type given by the data
type of the value assigned. Use this option to tell
ftnchek not to follow this rule but instead to use the
same rule as for standard PARAMETER statements. This
option does not apply to PARAMETER statements of the stan‐
dard form.
By default, all these source code options are turned off, except
for the vms-include option, which is on by default in the VMS
version..
See also: -f77, -include, -portability.
-style=list
Provides extra-picky warnings about obsolescent or old-fashioned
programming constructions. This option is helpful for efforts
to follow a modern programming style. (Most of the things com‐
plained about under this option are forbidden in the F subset
language.) By default, all warnings are turned off.
The list consists of keywords separated by commas or colons.
There are three special keywords: all to turn on all the
options, none to turn them all off, and help to print the list
of all the keywords with a brief explanation of each. If list
is omitted, -style is equivalent to -style=all, and -nostyle is
equivalent to -style=none. The warning keywords with their
meanings are as follows:
block-if:
Complain about arithmetic IF statement. Accept block IF
or logical IF (which controls a single statement).
construct-name:
Complain about unnamed block constructs: IF, DO, and
SELECT CASE. Note that if a construct name is present on
the opening statement of a construct, then it is required
to be present on all other component statements (ELSE, END
IF, etc.) of the construct. In that case a missing con‐
struct name on those statements generates a syntax error
regardless of this option. The purpose of this option is
to warn if the construct completely lacks the optional
name.
distinct-do:
Complain if two DO loops share a common terminator state‐
ment.
do-construct:
Complain if terminator of a DO loop is anything other than
an END DO or CONTINUE statement. This is the requirement
in order for the loop to meet the Fortran 90 definition of
a do-construct.
do-enddo:
Complain if terminator of a DO loop is anything other than
an END DO statement. (This option overrides the do-con‐
struct option, being even stricter.)
end-name:
Complain about the absence of the subprogram name on
structured END statements.
format-stmt:
Complain about the presence of FORMAT statements. Only
the FORMAT statements themselves are flagged, not the ref‐
erences to them in I/O lists.
goto: Complain about the presence of unconditional, computed or
assigned GOTO statements. Also complain about alternate
returns (but not about labels as subprogram arguments).
labeled-stmt:
Complain about the presence of labels (numbers) on state‐
ments other than FORMAT statements. (Since FORMAT state‐
ments are arguably convenient and not readily abused, com‐
plaints about them are controlled by the separate for‐
mat-stmt keyword.)
program-stmt:
Complain about the absence of a PROGRAM statement at the
head of the main program.
structured-end:
Complain about the use of a plain END statement to end a
subprogram, rather than a structured END statement (END
PROGRAM, END SUBROUTINE, END FUNCTION, or END BLOCK DATA).
See also: -f77, -f90, -f95, -pretty, -portability.
-symtab
A symbol table will be printed out for each module, listing all
identifiers mentioned in the module. This table gives the name
of each variable, its datatype, and the number of dimensions for
arrays. An asterisk (*) indicates that the variable has been
implicitly typed, rather than being named in an explicit type
declaration statement. The table also lists all subprograms
invoked by the module, all COMMON blocks declared, etc. Default
= no.
Also, for each module, a label table will be printed. The table
lists each label defined in the module; the line on which said
statement label is defined; and the statement type (executable,
format, or specification). The labels are listed in sequential
order.
Also printed is a table describing the I/O units used by the
module, together with information about how they are used: what
operations are performed, whether the access is sequential or
direct, and whether the I/O is formatted or unformatted.
See also: -calltree, -crossref, -list, -reference, -sort, -vcg.
-truncation=list
Warn about possible truncation (or roundoff) errors. Most of
these are related to integer arithmetic. By default, all warn‐
ings are turned on.
This setting provides detailed control over the warnings about
possible truncation errors. The list consists of keywords sepa‐
rated by commas or colons. Since all warnings are on by
default, include a keyword prefixed by no- to turn off a partic‐
ular warning. There are three special keywords: all to turn on
all the warnings about truncation, none to turn them all off,
and help to print the list of all the keywords with a brief
explanation of each. If list is omitted, -truncation is equiva‐
lent to -truncation=all, and -notruncation is equivalent to
-truncation=none. The warning keywords with their meanings are
as follows:
int-div-exponent:
use of the result of integer division as an exponent.
This suggests that a real quotient is intended. An exam‐
ple would be writing X**(1/3) to evaluate the cube root of
X. The correct expression is X**(1./3.).
int-div-real:
Conversion of an expression involving an integer division
to real. This suggests that a real quotient is intended.
int-div-zero:
division in an integer constant expression that yields a
result of zero.
int-neg-power:
exponentiation of an integer by a negative integer (which
yields zero unless the base integer is 1 in magnitude).
This suggests that a real base is intended.
promotion:
automatic conversion of a lower precision quantity to one
of higher precision. The loss of accuracy for real vari‐
ables in this process is comparable to the corresponding
demotion. No warning is given for promotion of integer
quantities to real since this is ordinarily exact.
real-do-index:
use of a non-integer DO index in a loop with integer
bounds. An integer DO index with real bounds is always
warned about regardless of this setting.
real-subscript:
use of a non-integer array subscript.
significant-figures:
overspecifying a single precision constant. This may
indicate that a double precision constant was intended.
size-demotion:
automatic conversion of a higher precision quantity to one
of lower precision of the same type. This warning only
occurs when an explicit size is used in declaring the type
of one or both operands in an assignment. For example, a
warning wil be issued where a REAL*8 variable is assigned
to a REAL variable, if the default wordsize of 4 is in
effect. A warning is also issued if a long integer is
assigned to a shorter one, for example, if an INTEGER
expression is assigned to an INTEGER*2 variable. There is
one exception to this last case, namely if the right hand
side of the assignment is a small literal constant (less
than 128). type-demotion: automatic conversion of a
higher precision quantity to one of lower precision of
different type. This warning includes conversion of real
quantities to integer, double precision to single preci‐
sion real, and assignment of a longer character string to
a shorter one.
The warnings about promotion and demotion also apply to complex
constants, considering the precision to be that of the real or
imaginary part. Warnings about promotions and demotions are
given only when the conversion is done automatically, e.g. in
expressions of mixed precision or in an assignment statement.
If intrinsic functions such as INT are used to perform the con‐
version, no warning is given.
See also: -portability, -wordsize.
-usage=list
Warn about unused or possible uninitialized variables, unused
common blocks, undefined or unused statement labels, and unused
or undefined subprograms. By default, all warnings are turned
on.
This setting provides detailed control over the warnings about
possible usage errors. The list consists of keywords separated
by commas or colons. Since all warnings are on by default,
include a keyword prefixed by no- to turn off a particular warn‐
ing. There are three special keywords: all to turn on all the
warnings about usage, none to turn them all off, and help to
print the list of all the keywords with a brief explanation of
each. If list is omitted, -usage is equivalent to -usage=all,
and -nousage is equivalent to -usage=none. These warnings cover
four main categories of objects: subprogram dummy arguments,
common blocks and variables, subprograms and functions, and
local variables. Warnings include undefined items, multiply
defined items, unused items, etc. The warning keywords with
their meanings are as follows:
arg-alias:
a scalar dummy argument is actually the same as another
and is (or may be) modified. The Fortran 77 standard
(section 15.9.3.6) prohibits modifying an argument that is
aliased to another.
arg-array-alias:
a dummy argument which is an array or array element is in
the same array as another and is modified. This flag is
similar to arg-alias but provides separate control over
array arguments. It is harder to tell if aliasing is
occurring in the case of arrays, so if ftnchek gives too
many false warnings, this flag allows the array-related
ones to be turned off without suppressing the warnings for
scalars.
arg-common-alias:
a scalar dummy argument is the same as a common variable
in the subprogram, and either is modified. This is also
prohibited by the Fortran 77 standard. If common checking
is not exact (see the -common setting), it is harder to
tell if aliasing is occurring, so the warning is given if
the variable is anywhere in a common block that is
declared by the subprogram.
arg-common-array-alias:
a dummy argument which is an array or array element is in
the same array as a common variable, and either is modi‐
fied. If common checking is not exact, the variable can
be anywhere in a common block that is declared by the sub‐
program.
arg-const-modified:
a subprogram modifies an argument which is a constant or
an expression. Such an action could cause anomalous
behavior of the program.
arg-unused:
a dummy argument is declared but never used. This is sim‐
ilar to the var-unused keyword described below, but
applies only to arguments.
com-block-unused:
a common block is declared but none of the variables in it
are used by any subprogram. This warning is suppressed if
the common strictness setting is 0.
com-block-volatile:
a common block may lose the definition of its contents if
common blocks are volatile. This option only has an
effect if the -common=volatile flag is in effect. See the
discussion of the -common setting above.
com-var-set-unused:
a common variable is assigned a value, but its value is
not used by any subprogram. This warning is suppressed if
the common strictness setting is 0.
com-var-uninitialized:
a common variable's value is used in some subprogram, but
is not set anywhere. Unfortunately, ftnchek does not do a
thorough enough analysis of the calling sequence to know
which routines are called before others. So warnings
about this type of error will only be given for cases in
which a variable is used in some routine but not set in
any other routine. Checking of individual COMMON vari‐
ables is done only if the -common setting is 3 (variable
by variable agreement). This warning is suppressed if the
common strictness setting is 0.
com-var-unused:
a common variable is declared but not used by any subpro‐
gram. This warning is suppressed if the common strictness
setting is 0.
do-index-modified:
a variable that is the index of a DO loop is modified by
some statement within the range of the loop. The Standard
permits an active DO variable to be modified only by the
incrementation mechanism of the DO statement.
ext-multiply-defined:
an external (a subroutine or function) is defined more
than once. Definition of an external means providing the
body of its source code.
ext-declared-only:
a name is declared in an EXTERNAL statement in some mod‐
ule, but is not defined or used anywhere.
ext-undefined:
an external is used (invoked) but not defined anywhere.
This option is equivalent to the -external flag. If the
subprogram is invoked more than once, those invocations
will still be checked for consistency.
ext-unused:
an external is defined (its subprogram body is present)
but it is not used. A subprogram is considered unused
even if it is invoked by some other subprogram, if it can‐
not be called from any thread of execution starting with
the main program. The agreement of the subprogram's argu‐
ments with its invocations is still checked even if this
warning is turned off. If there is no main program, then
this warning is issued only if the subprogram is not
invoked anywhere. This warning is suppressed in library
mode, but library mode has the additional effect of sup‐
pressing argument checking for unused routines.
label-undefined:
a statement refers to a label that has not been defined.
label-unused:
a statement label is defined, but never referred to.
var-set-unused:
a local variable is assigned a value, but that value is
not used.
var-uninitialized:
a local variable's value may be used before it is
assigned. Sometimes ftnchek makes a mistake in the warn‐
ings about local variable usage. Usually it errs on the
side of giving a warning where no problem exists, but in
rare cases it may fail to warn where the problem does
exist. See the section on Bugs for examples. If vari‐
ables are equivalenced, the rule used by ftnchek is that a
reference to any variable implies the same reference to
all variables it is equivalenced to. For arrays, the rule
is that a reference to any array element is treated as a
reference to all elements of the array.
var-unused:
a local variable is declared (for instance, in a type dec‐
laration) but is not used in the module. Does not apply
to dummy arguments: warnings about them are controlled by
the keyword arg-unused described above.
Note: In versions of ftnchek prior to 2.10, the -usage flag took
a numeric argument instead of a list of options. For the sake
of users who may have written scripts invoking ftnchek in this
way, the numeric form is still accepted. The numeric setting is
composed of three digits. The first digit (hundreds place) con‐
trols warnings about subprograms (functions and subroutines),
the second digit (tens place) warnings about common blocks and
common variables,, and the third digit (ones place) warnings
about local variables. Each digit controls warnings according
to the convention that a 1 means warn about undefined items and
variables that are used before set, a 2 means warn about items
that are unused, and a 3 means warn about both types. These
numbers are now converted to the appropriate values for the
above-listed keywords, except for com-block-volatile, which is
not affected by the numeric argument.
See also: -common, -declare, -extern, -library.
-vcg
Produce the call graph in the form of a VCG graph description.
This description is written to a separate file, with the same
stem as the file containing the main program, and suffix .vcg.
This file is able to be given directly to xvcg(1L) to visualize
the call graph. (If input is from the standard input, then the
graph description is sent to standard output.) This switch is
equivalent to -calltree=vcg. Default = no.
The VCG description as created is more complex than it need be.
VCG allows graphs and nested subgraphs: each subroutine is cre‐
ated as a subgraph nested inside its calling routines. This
allows you to interactively display subgraphs or summarise them.
The -vcg option for ftnchek was written by Dr. Philip Rubini of
Cranfield University, UK.
xvcg is a graph visualisation tool which runs under the X win‐
dows system. It is freely available from ftp.cs.uni-sb.de. It
was written by G. Sander of the University of Saarland, Germany.
See also: -calltree, -crossref, -reference, -sort.
-version
This option causes ftnchek to print a line giving the version
number, release date, and patch level of the program. If no
files are given, it then exits. If files are given, the effect
of this option is to include the patch level (normally omitted)
in the version information printed at the start of processing.
Default = no.
See also: -help.
-volatile
Assume that COMMON blocks are volatile. Default = no.
This flag is superseded by -common=volatile, and should no
longer be used. It may be eliminated in a future release of
ftnchek.
See also: -common, -usage.
-wordsize=num
Specifies the default word size to be num bytes. This is the
size of logical and single-precision numeric variables that are
not given explicit precisions. (Explicit precisions for non-
character variables are an extension to the Fortran 77 Standard,
and are given by type declarations such as REAL*8 X.) Double-
precision and complex variables will be twice this value, and
double complex variables four times. Quad-precision constants
and intrinsic function results will be four times this value.
Note that variables declared as REAL*16 will be regarded as quad
precision only if the word size is 4 bytes. Default = turn-on =
4 bytes.
The word size value does not matter for checking standard-con‐
forming programs that do not declare explicit precisions for
non-character variables or store Hollerith data in variables.
This setting also does not affect the default size of character
variables, which is always 1 byte. Hollerith constants also are
assumed to occupy 1 byte per character.
The word size is used to determine whether truncation occurs in
assignment statements, and to catch precision mismatches in sub‐
program argument lists and common block lists. The exact warn‐
ings that are issued will depend on the status of other flags.
Under both the -portability=mixed-size and the -nowordsize flag,
any mixing of explicit with default precision objects (character
expressions not included) is warned about. This applies to
arithmetic expressions containing both types of objects, and to
subprogram arguments and COMMON variables. Under control of the
-truncation=demotion and promotion options, a warning is given
for assignment of an expression to a shorter variable of the
same type, or for promotion of a lower precision value to higher
precision in an arithmetic expression or an assignment state‐
ment.
Giving a word size of 0, or equivalently, using -nowordsize
means that no default value will be assumed. This is equivalent
to specifying -portability=mixed-size. Use it to find cases of
mixing default and explicit precision, for example to flag
places where REAL*8 is treated as equivalent to DOUBLE PRECI‐
SION.
See also: -pointersize, -portability, -truncation.
-wrap=col
Controls the wrapping of error messages. Long error messages
that would run past the specified column will be broken up into
separate lines between the words of the message for better read‐
ability. If turned off with -nowrap, each separate error mes‐
sage will be printed on one line, leaving it up to the display
to wrap the message or truncate it. Default = turn-on = 79.
CHANGING THE DEFAULTSftnchek includes two mechanisms for changing the default values of all
options: by defining environment variables or by creating a preferences
file. When ftnchek starts up, it looks in its environment for any
variables whose names are composed by prefixing the string FTNCHEK_
onto the uppercased version of the option name. If such a variable is
found, its value is used to specify the default for the corresponding
switch or setting. In the case of settings (for example, the -common
strictness setting) the value of the environment variable is read as
the default setting value. In the case of switches, the default switch
will be taken as true or yes unless the environment variable has the
value 0 or NO.
Note that the environment variable name must be constructed with the
full-length option name, which must be in uppercase. For example, to
make ftnchek print a source listing by default, set the environment
variable FTNCHEK_LIST to 1 or YES or anything other than 0 or NO. The
names FTNCHEK_LIS (not the full option name) or ftnchek_list (lower
case) would not be recognized.
Here are some examples of how to set environment variables on various
systems. For simplicity, all the examples set the default -list switch
to YES.
1. UNIX, Bourne shell: $ FTNCHEK_LIST=YES
$ export FTNCHEK_LIST
2. UNIX, C shell: % setenv FTNCHEK_LIST YES
3. VAX/VMS: $ DEFINE FTNCHEK_LIST YES
4. MSDOS: $ SET FTNCHEK_LIST=YES
After processing any environment variables, ftnchek looks for a prefer‐
ences file containing options and settings. It will search in the fol‐
lowing order, using only the first file found: (1) .ftnchekrc in the
current directory, (2) ftnchek.ini in the current directory, (3)
.ftnchekrc in the user's home directory, (4) ftnchek.ini in the home
directory. If such a file is found, the options defined in it are used
as defaults in place of the built-in defaults and overriding any
defaults set in the environment..
Each option or setting in the preferences file must be on a separate
line. They are given in the same form as on the command line, except
without the initial dash. The preferences file can contain blank lines
and comments. Comments are introduced at any point in a line by a
space character (blank or tab) or the '#' character, and are terminated
by the end of the line.
Command-line options override the defaults set in the environment or in
the preferences file, in the same way as they override the built-in
defaults.
USING PROJECT FILES
This section contains detailed information on how to use project files
most effectively, and how to avoid some pitfalls.
One can divide the checks ftnchek does into two categories, local and
global. Local checking is restricted to within a single routine, and
catches things like uninitialized variables, unintended loss of preci‐
sion in arithmetic expressions, etc. This sort of checking can be done
on each subprogram independently. Furthermore, local checking of a
subprogram does not need to be repeated when some other subprogram is
changed. Global checking catches things like calling a subroutine with
the wrong argument types, or disagreeing in common block declarations.
It requires looking at the whole set of subprograms interacting with
each other.
The purpose of project files is to allow the local checking and global
checking steps to be separated. Assuming that each subprogram is in
its own source file, you can run ftnchek once on each one to do local
checking while suppressing global checking. Then ftnchek can be run
once on all the project files together to do the global checking. The
sample makefile below shows how to automate this task. The ``.f.prj''
target updates a project file for a particular file any time the source
file changes. The information needed for global checking is saved in
the project file. The ``check'' target does the combined global check‐
ing. Typically ``make check'' would repeat the ``ftnchek -project''
step only on changed source files, then do the global check. This is
obviously a big advantage for large programs, when many subprograms
seldom if ever change.
It is best when using project files to place each subprogram in a sepa‐
rate source file. If each source file may contain more than one sub‐
program, it complicates the definition of ``local'' and ``global''
checking because there is some inter-module checking that is contained
within a file. ftnchek tries to do the right thing in this case, but
there are some complications (described below) due to the trade-off
between avoiding re-doing cross-checks and preserving information about
the program's structure.
Ordinarily, to do the least amount of re-checking, project files should
be created with the -library flag in effect and trimming turned on. In
this mode, the information saved in the project file consists of all
subprogram declarations, all subprogram invocations not resolved by
declarations in the same file, and one instance of each COMMON block
declaration. This is the minimum amount of information needed to check
agreement between files.
If the source file contains more than one routine, there are some pos‐
sible problems that can arise from creating the project file in library
mode, because the calling hierarchy among routines defined within the
file is lost. Also, if the routines in the file make use of COMMON
blocks that are shared with routines in other files, there will not be
enough information saved for the correct checking of set and used sta‐
tus of COMMON blocks and COMMON variables according to the -usage set‐
ting. Therefore if you plan to use project files when -usage checking
is turned on (which is the default situation), and if multiple routines
in one project file share COMMON blocks with routines in other files,
the project files should be created with the -library flag turned off.
In this mode, ftnchek saves, besides the information listed above, one
invocation of each subprogram by any other subprogram in the same file,
and all COMMON block declarations. This means that the project file
will be larger than necessary, and that when it is read in, ftnchek may
repeat some inter-module checks that it already did when the project
file was created. If each project file contains only one module, there
is no loss of information in creating the project files in library
mode.
Because of the possible loss of information entailed by creating a
project file with the -library flag in effect, whenever that project
file is read in later, it will be treated as a library file regardless
of the current setting of the -library flag. On the other hand, a
project file created with library mode turned off can be read in later
in either mode.
The foregoing discussion assumes that the trimming options of the
-project setting are turned on when the project file is created. This
is the normal situation. The no-trim options of the -project setting
are provided in case one wants to use the project files for purposes
other than checking the program with ftnchek. For instance, one could
write a Perl script to analyze the project files for information about
how the different subprograms are called. You should not use the
no-trim options to deal with the issues of information loss discussed
above, since they cause more information than necessary to be stored.
This makes the project files bigger and causes ftnchek to do more work
later when it reads them to check your complete program. Ordinarily,
you should use the -library option to control how much information to
store for later use by ftnchek in checking your program.
Here is an example of how to use the UNIX make utility to automatically
create a new project file each time the corresponding source file is
altered, and to check the set of files for consistency. Add these
lines to your makefile. The example assumes that a macro OBJS has been
defined which lists all the names of object files to be linked together
to form the complete executable program. (In this makefile, the
indented lines should each begin with a tab, not blanks.) If any
source file contains multiple routines that share common blocks among
themselves, then the no-com-\* option should be removed from NOGLOBAL,
and/or drop the -library flag.
# tell make what a project file suffix is
.SUFFIXES: .prj
# these options suppress global checks.
NOGLOBAL=-usage=no-ext-undefined,no-com-\*
# tell make how to create a .prj file from a .f file
.f.prj:
ftnchek-project $(NOGLOBAL) -library $<
# set up macro PRJS containing project filenames
PRJS= $(OBJS:.o=.prj)
# "make check" will check everything that has been changed.
check: $(PRJS)
ftnchek $(PRJS)
When a program uses many routines defined in a large number of differ‐
ent source files in different directories, it can be cumbersome to
specify all the different project files needed to check the program
properly. To deal with such cases, ftnchek allows project files to be
concatenated into a single large file. This single file can then be
given to ftnchek to provide the information for checking the use of any
or all of the routines defined in the combined project files. When
using such a ``library'' project file, you may want ftnchek's error
reports to document precisely the name of the file where the specific
function is defined. If the various source files are in several direc‐
tories, an error report that gives only the file name may be ambiguous,
and rather should include the path to the file. The solution is to
create each of the individual project files by giving the complete path
to the source file. Then this complete path will appear in the error
reports. For example, suppose that all of the library subprogram
source files are in subdirectories of a directory named /util/lib.
Then the individual project files could first be created by a command
such as
find /util/lib -name '*.f' -execftnchek-project '{}' ';'
(Possibly other options would be provided to ftnchek as discussed
above. Also, this step could be handled instead by a revised makefile
rule that would provide the complete source file path instead of just
the local name when invoking ftnchek.) Next, concatenate all of these
project files manually.
find /util/lib -name '*.prj' -exec cat '{}' ';' > ourlib.prj
Then a program source file can be checked by using the command
ftnchek prog.f ... -lib ourlib.prj
and an error message related to any library routine will include the
full path to the routine's source file.
At present, there is no archive utility like ar to manage the contents
of a concatenated project file like the one in the illustration above.
If changes are made to one of the library routines, the only way to
update the combined project file is to concatenate all the individual
project files once again. Such a utility would be quite easy to write.
Someone should do so and contribute it to the ftnchek effort.
AN EXAMPLE
The following simple Fortran program illustrates the messages given by
ftnchek. The program is intended to accept an array of test scores and
then compute the average for the series.
C AUTHORS: MIKE MYERS AND LUCIA SPAGNUOLO
C DATE: MAY 8, 1989
C Variables:
C SCORE -> an array of test scores
C SUM -> sum of the test scores
C COUNT -> counter of scores read in
C I -> loop counter
REAL FUNCTION COMPAV(SCORE,COUNT)
INTEGER SUM,COUNT,J,SCORE(5)
DO 30 I = 1,COUNT
SUM = SUM + SCORE(I)
30 CONTINUE
COMPAV = SUM/COUNT
END
PROGRAM AVENUM
C
C MAIN PROGRAM
C
C AUTHOR: LOIS BIGBIE
C DATE: MAY 15, 1990
C
C Variables:
C MAXNOS -> maximum number of input values
C NUMS -> an array of numbers
C COUNT -> exact number of input values
C AVG -> average returned by COMPAV
C I -> loop counter
C
PARAMETER(MAXNOS=5)
INTEGER I, COUNT
REAL NUMS(MAXNOS), AVG
COUNT = 0
DO 80 I = 1,MAXNOS
READ (5,*,END=100) NUMS(I)
COUNT = COUNT + 1
80 CONTINUE
100 AVG = COMPAV(NUMS, COUNT)
END
The compiler gives no error messages when this program is compiled.
Yet here is what happens when it is run:
$ run average
70
90
85
<EOF>
$
What happened? Why didn't the program do anything? The following is
the output from ftnchek when it is used to debug the above program:
$ ftnchek-list -symtab average
FTNCHEK Version 3.3 November 2004
File average.f:
1 C AUTHORS: MIKE MYERS AND LUCIA SPAGNUOLO
2 C DATE: MAY 8, 1989
3
4 C Variables:
5 C SCORE -> an array of test scores
6 C SUM -> sum of the test scores
7 C COUNT -> counter of scores read in
8 C I -> loop counter
9
10 REAL FUNCTION COMPAV(SCORE,COUNT)
11 INTEGER SUM,COUNT,J,SCORE(5)
12
13 DO 30 I = 1,COUNT
14 SUM = SUM + SCORE(I)
15 30 CONTINUE
16 COMPAV = SUM/COUNT
^
Warning near line 16 col 20: integer quotient expr SUM/COUNT converted to
real
17 END
Module COMPAV: func: real
Variables:
Name Type Dims Name Type Dims Name Type Dims Name Type Dims
COMPAV real COUNT intg I intg* J intg
SCORE intg 1 SUM intg
* Variable not declared. Type has been implicitly defined.
Warning in module COMPAV: Variables declared but never referenced:
J declared at line 11
Warning in module COMPAV: Variables may be used before set:
SUM used at line 14
SUM set at line 14
Statement labels defined:
Label Line StmtType
<30> 15 exec
18
19
20 PROGRAM AVENUM
21 C
22 C MAIN PROGRAM
23 C
24 C AUTHOR: LOIS BIGBIE
25 C DATE: MAY 15, 1990
26 C
27 C Variables:
28 C MAXNOS -> maximum number of input values
29 C NUMS -> an array of numbers
30 C COUNT -> exact number of input values
31 C AVG -> average returned by COMPAV
32 C I -> loop counter
33 C
34
35 PARAMETER(MAXNOS=5)
36 INTEGER I, COUNT
37 REAL NUMS(MAXNOS), AVG
38 COUNT = 0
39 DO 80 I = 1,MAXNOS
40 READ (5,*,END=100) NUMS(I)
41 COUNT = COUNT + 1
42 80 CONTINUE
43 100 AVG = COMPAV(NUMS, COUNT)
44 END
Module AVENUM: prog
External subprograms referenced:
COMPAV: real*
Variables:
Name Type Dims Name Type Dims Name Type Dims Name Type Dims
AVG real COUNT intg I intg MAXNOS intg*
NUMS real 1
* Variable not declared. Type has been implicitly defined.
Warning in module AVENUM: Variables set but never used:
AVG set at line 43
I/O Operations:
Unit ID Unit No. Access Form Operation Line
5 SEQ FMTD READ 40
Statement labels defined:
Label Line StmtType Label Line StmtType
<80> 42 exec <100> 43 exec
0 syntax errors detected in file average.f
6 warnings issued in file average.f
Warning: Subprogram COMPAV argument data type mismatch at position 1:
Dummy arg SCORE in module COMPAV line 10 file average.f is type intg
Actual arg NUMS in module AVENUM line 43 file average.f is type real
According to ftnchek, the program contains variables which may be used
before they are assigned an initial value, and variables which are not
needed. ftnchek also warns the user that an integer quotient has been
converted to a real. This may assist the user in catching an unintended
roundoff error. Since the -symtab flag was given, ftnchek prints out a
table containing identifiers from the local module and their corre‐
sponding datatype and number of dimensions. Finally, ftnchek warns
that the function COMPAV is not used with the proper type of arguments.
With ftnchek's help, we can debug the program. We can see that there
were the following errors:
1. SUM and COUNT should have been converted to real before doing the
division.
2. SUM should have been initialized to 0 before entering the loop.
3. AVG was never printed out after being calculated.
4. NUMS should have been declared INTEGER instead of REAL.
We also see that I, not J, should have been declared INTEGER in func‐
tion COMPAV. Also, MAXNOS was not declared as INTEGER, nor COMPAV as
REAL, in program AVENUM. These are not errors, but they may indicate
carelessness. As it happened, the default type of these variables
coincided with the intended type.
Here is the corrected program, and its output when run:
C AUTHORS: MIKE MYERS AND LUCIA SPAGNUOLO
C DATE: MAY 8, 1989
C
C Variables:
C SCORE -> an array of test scores
C SUM -> sum of the test scores
C COUNT -> counter of scores read in
C I -> loop counter
C
REAL FUNCTION COMPAV(SCORE,COUNT)
INTEGER SUM,COUNT,I,SCORE(5)
C
SUM = 0
DO 30 I = 1,COUNT
SUM = SUM + SCORE(I)
30 CONTINUE
COMPAV = FLOAT(SUM)/FLOAT(COUNT)
END
C
C
PROGRAM AVENUM
C
C MAIN PROGRAM
C
C AUTHOR: LOIS BIGBIE
C DATE: MAY 15, 1990
C
C Variables:
C MAXNOS -> maximum number of input values
C NUMS -> an array of numbers
C COUNT -> exact number of input values
C AVG -> average returned by COMPAV
C I -> loop counter
C
C
INTEGER MAXNOS
PARAMETER(MAXNOS=5)
INTEGER I, NUMS(MAXNOS), COUNT
REAL AVG,COMPAV
COUNT = 0
DO 80 I = 1,MAXNOS
READ (5,*,END=100) NUMS(I)
COUNT = COUNT + 1
80 CONTINUE
100 AVG = COMPAV(NUMS, COUNT)
WRITE(6,*) 'AVERAGE =',AVG
END
$ run average
70
90
85
<EOF>
AVERAGE = 81.66666
$
With ftnchek's help, our program is a success!
INTERPRETING THE OUTPUT
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
the version of the parser generator and whether it is GNU bison or UNIX
yacc). This type of error message cannot be suppressed. Be aware that
this type of error often means that ftnchek has not properly inter‐
preted the statement where the error occurs, so that its subsequent
checking operations will be compromised. You should eliminate all syn‐
tax 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 below. 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 condi‐
tions 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 dif‐
ferent platforms. For example, equivalencing real and integer vari‐
ables 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 porta‐
bility, 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 vari‐
able names or the lack of space between a keyword and a variable can
convey the wrong impression to the reader. These messages can be sup‐
pressed 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 subpro‐
gram. These warnings are controlled by the -common and -arguments set‐
tings 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 pro‐
gram.
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 com‐
pilers 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 For‐
tran 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 declara‐
tions 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 fol‐
lowed by a long (e.g. double precision real) item, the latter
may not be aligned correctly. Controlled by -portability=com‐
mon-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 dif‐
ferent 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 vari‐
ables, 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 parame‐
ter, 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 state‐
ment label), occurring immediately after a GOTO statement, can‐
not 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 pro‐
gram. 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 subse‐
quent 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. Con‐
trolled 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 dif‐
ferently, and also it is possible that files sent by electronic
mail will have the tabs converted to blanks in some way. There‐
fore 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 -portabil‐
ity=real-do.
Possibly it is an array which was not declared
This message is appended to warnings related to a function invo‐
cation or to an argument type mismatch, for which the possibil‐
ity 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 invoca‐
tions. 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 sig‐
nificant, 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=mul‐
tiple-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, mak‐
ing 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 argu‐
ment 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 num‐
ber 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 subpro‐
gram, 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 sub‐
program 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 hav‐
ing 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 -argu‐
ments 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 -trunca‐
tion=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 char‐
acter 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 differ‐
ently 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. State‐
ments 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 divi‐
sion 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 simi‐
lar 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. Con‐
trolled 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 func‐
tion. 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 nonstan‐
dard intrinsics, you can use the -intrinsic setting to cause
ftnchek to recognize it.
LIMITATIONS AND EXTENSIONSftnchek accepts ANSI standard Fortran-77 programs with some minor limi‐
tations and numerous common extensions.
Limitations:
The dummy arguments in statement functions are treated like
ordinary variables of the program. That is, their scope is the
entire subprogram, not just the statement function definition.
The checking of FORMAT statements is lax, tolerating missing
separators (comma, etc.) between format descriptors in places
where the Standard requires them, and allowing .d fields on
descriptors that should not have them. It does warn under
-f77=format-edit-descr about nonstandard descriptor types (like
O), and supported extensions.
There are some syntactic extensions and Fortran 90 elements that
ftnchek accepts but does very little checking. For instance,
pointer usage (whether the nonstandard Cray syntax or the For‐
tran 90 syntax) is not checked other than for set and used sta‐
tus. It is hoped that some day more thorough checking will be
implemented, but for now the user should regard the acceptance
of these syntactic features simply as a convenience to enable
checking of other aspects of code that contains them. See the
section Extensions for specifics about what features are
accepted but not fully checked.
If a user-supplied subprogram has the same name as one of the
nonstandard intrinsic functions recognized by ftnchek, it must
be declared in an EXTERNAL statement in any routine that invokes
it. Otherwise it will be subject to the checking normally given
to the intrinsic function. Since the nonstandard intrinsics are
not standard, this EXTERNAL statement is not required by the
Fortran 77 Standard. Using the -intrinsic=none setting, recog‐
nition of most nonstandard intrinsics (excepting only those
needed to support the double complex data type) can be turned
off. See the lists of supported nonstandard intrinsic functions
under the discussion of the -intrinsic setting above.
Extensions:
All of these extensions (except lower-case characters) will gen‐
erate warnings if the relevant -f77 option is set. Some of the
extensions listed below are part of the Fortran-90 Standard.
These are indicated by the notation (F90).
Tabs are permitted, and translated into equivalent blanks which
correspond to tab stops every 8 columns. The standard does not
recognize tabs. Note that some compilers allow tabs, but treat
them differently. The treatment defined for DEC FORTRAN can be
achieved using the -source=dec-tab setting.
Strings may be delimited by either quote marks or apostrophes.
A sequence of two delimiter characters is interpreted as a sin‐
gle embedded delimiter character. (F90)
Strings may contain UNIX-style backslash escape sequences. They
will be interpreted as such if the -source=unix-backslash set‐
ting is given. Otherwise the backslash character will be
treated as a normal printing character.
Source code can be in either Fortran 90 free format or tradi‐
tional fixed format. (F90)
A semicolon is allowed as a statement separator. (F90)
Lower case characters are permitted, and are converted inter‐
nally to uppercase except in character strings. The standard
specifies upper case only, except in comments and strings.
(F90)
Hollerith constants are permitted, in accordance with the For‐
tran 77 Standard, appendix C. They should not be used in
expressions, or confused with datatype CHARACTER.
The letter 'D' (upper or lower case) in column 1 is treated as
the beginning of a comment. There is no option to treat such
lines as statements instead of comments.
Statements may be longer than 72 columns provided that the set‐
ting -columns was used to increase the limit. According to the
standard, all text from columns 73 through 80 is ignored, and no
line may be longer than 80 columns.
Variable names may be longer than six characters. The standard
specifies six as the maximum. ftnchek permits names up to 31
characters long (F90).
Variable names may contain underscores and dollar signs (or
other non-alphabetic characters as specified by the -identi‐
fier-chars option). These characters are are treated the same
as alphabetic letters. The default type for variables beginning
with these characters is REAL. In IMPLICIT type statements
specifying a range of characters, the dollar sign follows Z and
is followed by underscore. (Any other user-defined characters
are treated the same as the dollar sign.) Fortran 90 permits
underscores in variable names.
The UNIX version tolerates the presence of preprocessor direc‐
tives, namely lines beginning with the pound sign (#). These
are treated as comments, except for #line directives, which are
interpreted, and are used to set the line number and source file
name for warnings and error messages. Note that #include direc‐
tives are not processed by ftnchek. Programs that use them for
including source files should be passed through the preprocessor
before being input to ftnchek. As noted below, ftnchek does
process INCLUDE statements, which have a different syntax. An
optional program, ftnpp(1L) (available separately) provides
preprocessing that properly handles INCLUDE files.
The Fortran 90 DO ... ENDDO control structure is permitted.
The CYCLE and EXIT statements are accepted. All of these may
have an optional do-construct name, but construct names are not
checked for consistency. (F90)
The Fortran 90 SELECT CASE construct is accepted. (F90)
Construct names are also accepted on IF, THEN, ELSE, ENDIF and
SELECT CASE statements. (F90)
The ACCEPT and TYPE statements (for terminal I/O) are permitted,
with the same syntax as PRINT.
The so-called ``Cray pointer'' syntax is tolerated. It is not
the same as the Fortran 90 POINTER statement. There is no real
checking of the statement other than basic syntax. The form of
this statement is
POINTER (pointer, pointee) [,(pointer, pointee)]
The pointer variables are assigned a data type of INTEGER *4.
Usage checking of the pointee variables is suppressed, since in
practice they are accessed indirectly via the pointers.
The following Fortran 90 pointer related syntaxes are accepted:
ALLOCATABLE, POINTER, and TARGET statements and the same
attributes in type declarations; ALLOCATE, DEALLOCATE, and NUL‐
LIFY executable statements; pointer assignment using => opera‐
tor; and the intrinsic functions ALLOCATED and ASSOCIATED. Lit‐
tle semantic checking of pointer variables and operations is
done beyond basic set and used status. For instance, there is
no checking for such errors as dangling pointers, or use of
unallocated arrays.
Statements may have any number of continuation lines. The For‐
tran 77 and Fortran 90 standards allow a maximum of 19 in fixed
source form. The Fortran 90 standard allows a maximum of 39 in
free source form.
Relational (comparison) operators composed of punctuation,
namely: < <= == /= > >= are allowed. (F90)
Inline comments, beginning with an exclamation mark, are permit‐
ted. (F90)
NAMELIST I/O is supported. The syntax is the same as in Fortran
90.
FORMAT statements can contain a dollar sign to indicate suppres‐
sion of carriage-return. An integer expression enclosed in
angle brackets can be used anywhere in a FORMAT statement where
the Fortran 77 Standard allows an integer constant (except for
the length of a Hollerith constant), to provide a run-time value
for a repeat specification or field width.
Nonstandard keywords are allowed in I/O statements, correspond‐
ing to those in VMS Fortran.
The IMPLICIT NONE statement is supported. The meaning of this
statement is that all variables must have their data types
explicitly declared. Rather than flag the occurrences of such
variables with syntax error messages, ftnchek waits till the end
of the module, and then prints out a list of all undeclared
variables, as it does for the -declare option. (F90)
Data types INTEGER, REAL, COMPLEX, and LOGICAL are allowed to
have an optional precision specification in type declarations.
For instance, REAL*8 means an 8-byte floating point data type.
The REAL*8 datatype is not necessarily considered equivalent to
DOUBLE PRECISION, depending on the -wordsize setting. The For‐
tran 77 Standard allows a length specification only for CHARAC‐
TER data.
ftnchek supports the DOUBLE COMPLEX type specification for a
complex quantity whose real and imaginary parts are double pre‐
cision. Mixed-mode arithmetic involving single-precision com‐
plex with double-precision real data, prohibited under the Stan‐
dard, yields a double complex result.
Combined type declarations and data-statement-like initializers
are accepted. These have the form of a standard Fortran 77 type
declaration, followed by a slash-delimited list of constants
like that used in a DATA statement. An example of the syntax is
INTEGER N / 100 /
This bastard form of initializing declaration was not adopted in
Fortran 90. Such declarations should be written using the stan‐
dard form described below, which is accepted by ftnchek.
There is limited support for Fortran 90 attribute-based type
declarations. This style of declaration is distinguished by the
use of a double colon (::) between the list of attributes and
the list of declared variables. The features supported may be
adequate for novice programmers, but are not yet sufficient for
professional-quality Fortran 90 programs. I hope to add support
for more features in future releases. I invite volunteers to
assist in this task. See the ToDo file in the source code dis‐
tribution for details. The attributes currently accepted,
besides all the usual data types, are DIMENSION, EXTERNAL,
INTRINSIC, PARAMETER, and SAVE. The new form of declaration
also allows assignment of values to the variables declared. At
present, the (LEN=value) form of specifying character lengths is
also accepted. Kind specifications, using (KIND=value) are
parsed but are not processed: all kinds are treated as default
kind. Also, there is little checking of these declarations
beyond basic syntax.
Many commonly found nonstandard intrinsic functions are pro‐
vided. See the discussion of -intrinsic for a list of functions
and how to control which ones are recognized.
Argument checking is not tight for those nonstandard intrinsics
that take arrays or mixed argument types.
ftnchek permits the INCLUDE statement, which causes inclusion of
the text of the given file. The syntax is
INCLUDE 'filename'
This is compatible with Fortran 90. If the -source=vms-include
option is given, ftnchek follows VMS conventions with respect to
this statement: it assumes a default extension of .for if no
filename extension is given, and allows the qualifier /[NO]LIST
following the filename, to control the listing of the included
file. There is no support for including VMS text modules.
In diagnostic output relating to items contained in include
files, the location of the error is specified by both its loca‐
tion in the include file and the location in the parent file
where the file was included.
ftnchek accepts PARAMETER statements which lack parentheses.
These will be warned about if the -f77=param-noparen flag is
given.
ftnchek accepts PARAMETER definitions that involve intrinsic
functions and exponentiation by a non-integer exponent. Both of
these cases are prohibited by the Fortran 77 Standard, and will
be warned about if the -f77=param-intrinsic flag is given. If
an intrinsic function value is a compile-time integer constant,
ftnchek will evaluate it. This allows better checking if the
parameter is used in declaring array sizes. Fortran 90 allows
intrinsic functions in PARAMETER definitions.
The intrinsic functions that are evaluated are:
ABS IABS DIM IDIM MAX
MAX0 MIN MIN0 MOD SIGN
ISIGN LEN ICHAR INDEX
The functions of integer arguments are evaluated only if the
arguments are integer constant expressions. (These may involve
integer constants, parameters, and evaluated intrinsic func‐
tions.) The function LEN is evaluated if its argument is an
expression involving only character constants and variables
whose length is not adjustable. The functions ICHAR and INDEX
are evaluated only if the arguments are character constants.
ftnchek gives a warning if it needs the value of some intrinsic
function that is not evaluated.
NEW FEATURES
Here are the changes from Version 3.2 to Version 3.3:
1. Front-end has been rewritten for unlimited lookahead, eliminating
the longstanding bug that caused incorrect interpretation of state‐
ments whose ambiguity was not resolved in the first line.
2. The -mkhtml option is now available in the MS-DOS version.
3. Added support for Fortran 90 pointer related syntax: ALLOCATE,
DEALLOCATE, and NULLIFY statements; the ALLOCATABLE, POINTER and
TARGET attributes in type declarations; the pointer assigment oper‐
ator => and intrinsic functions ALLOCATED and ASSOCIATED; and
deferred-shape array declarations. At present these new syntax
features are accepted but not properly checked. This feature was
added by Robert Landrito.
4. The -f77 and -f90 pointer option controlling warnings about ``Cray
pointers'' has been renamed to cray-pointer. The -f77=pointer
option now instead controls warnings for code containing Fortran 90
pointer-related syntax.
5. Re-implemented -mkhtml processing so it is now much faster on
source files containing many routines.
6. Changed the arrangement of the test directory so there is no longer
any need to modify the distribution in order to run the test suite
(check.bat) under MS-DOS.
7. Fixed bug in reading numeric settings on command line when setting
name abbreviated to 3 characters.
8. Fixed bug causing spurious warning for a GOTO referring to a
labeled END statement when the statement before END was a FORMAT.
9. New flag -f77=character to control warnings about extensions to the
Fortran 77 character data type. Accompanying this new flag is sup‐
port for Fortran 90 rules for character variable declarations that
evaluate to zero or negative length, allowing them and treating
negative length values as zero.
10. Fixed minor bug in printing of comments and blank lines following
last END statement in -list mode.
BUGSftnchek still has much room for improvement. Your feedback is appreci‐
ated. We want to know about any bugs you notice. Bugs include not
only cases in which ftnchek issues an error message where no error
exists, but also if ftnchek fails to issue a warning when it ought to.
Note, however, that ftnchek is not intended to catch all syntax errors
(see section on Limitations). Also, it is not considered a bug for a
variable to be reported as used before set, if the reason is that the
usage of the variable occurs prior in the text to where the variable is
set. For instance, this could occur when a GOTO causes execution to
loop backward to some previously skipped statements. ftnchek does not
analyze the program flow, but assumes that statements occurring earlier
in the text are executed before the following ones.
We especially want to know if ftnchek crashes for any reason. It is
not supposed to crash, even on programs with syntax errors. Sugges‐
tions are welcomed for additional features which you would find useful.
Tell us if any of ftnchek's messages are incomprehensible. Comments on
the readability and accuracy of this document are also welcome.
You may also suggest support for additional extensions to the Fortran
language. These will be included only if it is felt that the exten‐
sions are sufficiently widely accepted by compilers.
If you find a bug in ftnchek, first consult the list of known bugs
below to see if it has already been reported. Also check the section
entitled ``Limitations and Extensions'' above for restrictions that
could be causing the problem. If you do not find the problem docu‐
mented in either place, then send a report including
1. The operating system and CPU type on which ftnchek is running.
2. The version of ftnchek and values of any environment options or
settings defined in startup file. (Capturing the output of ftnchek-help is useful for this.)
3. A brief description of the bug.
4. If possible, a small sample program showing the bug.
The report should be sent to Dr. Robert Moniot (see contact information
in section entitled ``Installation and Support'').
Highest priority will be given to bugs which cause ftnchek to crash.
Certain problems that arise when checking large programs can be fixed
by increasing the sizes of the data areas in ftnchek. (These problems
are generally signaled by error messages beginning with ``Oops''.) The
simplest way to increase the table sizes is by recompiling ftnchek with
the LARGE_MACHINE macro name defined. Consult the makefile and README
file for the method of doing this.
The following is a list of known bugs.
1. Bug: Used-before-set message is suppressed for any variable which
is used as the loop index in an implied-do loop, even if it was in
fact used before being set in some earlier statement. For example,
consider J in the statement
WRITE(5,*) (A(J), J=1,10)
Here ftnchek parses the I/O expression, A(J), where J is used,
before it parses the implied loop where J is set. Normally this
would cause ftnchek to report a spurious used-before-set warning
for J. Since this report is usually in error and occurs fairly
commonly, ftnchek suppresses the warning for J altogether.
Prognosis: A future version of ftnchek is planned which will han‐
dle implied-do loops correctly.
2. Bug: Variables used (not as arguments) in statement-function sub‐
programs do not have their usage status updated when the statement
function is invoked.
Prognosis: To be fixed in a future version of ftnchek.
3. Bug: VAX version does not expand wildcards in filenames on the com‐
mand line if they are followed without space by an option, e.g.
ftnchek *.f/calltree would not expand the *.f. This is because
VMS-style options without intervening space are not supported by
the GNU shell_mung routine that is used to expand wildcards.
Prognosis: unlikely to be fixed.
4. Bug: checking for nonstandard format edit descriptors is done only
in FORMAT statements, not in character strings used as formats.
Prognosis: may be fixed someday.
ACKNOWLEDGEMENTSftnchek was designed by Dr. Robert Moniot, professor at Fordham Univer‐
sity. During the academic year of 1988-1989, Michael Myers and Lucia
Spagnuolo developed the program to perform the variable usage checks.
During the following year it was augmented by Lois Bigbie to check sub‐
program arguments and COMMON block declarations. Brian Downing
assisted with the implementation of the INCLUDE statement. John Quinn
wrote the common block usage checks. Heba Elsayed wrote the label ta‐
ble printout and label usage checks. Nelson H. F. Beebe of the Univer‐
sity of Utah added most of the new code to implement the -makedcls fea‐
ture and wrote the dcl2inc script. The -mkhtml feature was contributed
by Mark McVeigh of Framatome ANP, Inc. The -reference feature was con‐
tributed by Gerome Emmanuel, Ecole des mines, U. Nancy (slightly modi‐
fied). The -vcg option was contributed by Dr. Philip Rubini of Cran‐
field University, UK. The support for Cray pointer syntax was provided
by John Dannenhoffer of United Technologies Research Center. John C.
Bollinger of Indiana University added the parser syntax for the SELECT
CASE construct. Robert Landrito added the parser syntax for F90
pointer-related features. Additional features will be added as time
permits. As of Version 2.5, the name was changed from forchek to
ftnchek, to avoid confusion with a similar program named forcheck,
developed earlier at Leiden University.
We would like to thank John Amor of the University of British Columbia,
Reg Clemens of the Air Force Phillips Lab in Albuquerque, Markus
Draxler of the University of Stuttgart, Victor Eijkhout of the Univer‐
sity of Tennessee at Knoxville, Greg Flint of Purdue University, Daniel
P. Giesy of NASA Langley Research Center, Fritz Keinert of Iowa State
University, Judah Milgram of the University of Maryland College Park,
Hugh Nicholas of the Pittsburgh Supercomputing Center, Dan Severance of
Yale University, Phil Sterne of Lawrence Livermore National Laboratory,
Larry Weissman of the University of Washington, Warren J. Wiscombe of
NASA Goddard, and Nelson H. F. Beebe of the University of Utah, for
pointing out bugs and suggesting some improvements. Stefan A.
Deutscher, Gunnar Duus, Clive Page of the University of Leicester,
Stephan Wefing of Heidelberg University, and Bob Wells of Oxford Uni‐
versity were extremely helpful as alpha testers. We also thank Jack
Dongarra for putting ftnchek into the netlib library of publicly avail‐
able software.
INSTALLATION AND SUPPORT
The ftnchek program is free software. It can be obtained by anonymous
ftp from many software servers, including ftp://netlib.org/fortran .
Note that on Netlib the distribution is named ftnchek.tar.gz whereas on
most other servers the file name includes the version number, e.g.
ftnchek-3.3.0.tar.gz. If the file extension is .Z, uncompress with the
Unix uncompress(1) utility. If the file extension is .gz, uncompress
with the GNU gunzip(1L) program. Then use tar(1) to unpack the files
into a subdirectory.
Installation requires a C compiler for your computer. See the INSTALL
file provided with the distribution for instructions on installing
ftnchek on your system. Executable binary for particular systems such
as IBM PC or Macintosh, as available, can be obtained by anonymous ftp
from ftp://ftp.dsm.fordham.edu/pub/ftnchek . Assistance in preparing
such executable binary forms is welcome.
The nroff version of this document is named ftnchek.man. On UNIX sys‐
tems, this file can be used as the man page, but actually it is a
multi-purpose source file which is used to produce the other forms of
the documentation. The cleaned-up man page document, created during
installation of ftnchek, is named ftnchek.1. The distribution also
includes a plain ASCII version named ftnchek.doc, a PostScript version
named ftnchek.ps, an HTML version in directory html, and a VMS HELP
version named ftnchek.hlp.
Information about the latest version and the status of the project can
be obtained by visiting ftnchek's home page, http://www.dsm.ford‐
ham.edu/~ftnchek . For further information and to report bugs, you may
contact Dr. Robert Moniot, whose contact information can be found by a
Web search for his name and Fordham University. (E-mail address is not
provided here because it attracts unsolicited commercial e-mail, but it
is easily constructed by combining his last name with the name of the
university and the edu domain.)
SEE ALSOdcl2inc(1L), dtoq(1L), dtos(1L), f77(1), fd2s(1L), fs2d(1L), ftnpp(1L),
pfort(1L), qtod(1L), sf3(1L), stod(1L). xsf3(1L), xvcg(1L).
November 2004 FTNCHEK 3.3(1L)
