ftnchek (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 operation. 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 compiler. 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.
The brackets indicate something which is optional. The brackets themselves 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 informational messages, but not the program listing or symbol tables.
Each option begins with the '-' character. (On VAX/VMS or MS-DOS systems 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 characters 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 setting 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.
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:
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 processor.
If no filename is given, ftnchek will read input from the standard input.
The option names in the following list are in alphabetical order.
Controls warnings about mismatches between actual and dummy subprogram 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 keywords with their meanings are as follows:
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.
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 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 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:
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 elements. There is no check of whether multi-dimensional arrays agree in the size of each dimension separately.
See also: -arguments, -library, -usage.
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.
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 equivalent to -calltree=tree, and -nocalltree is equivalent to -calltree=none. By default no call graph is printed.
The keywords which control which format is used are as follows:
The following keywords control options affecting the output:
For tree format, The call graph is printed out starting from the main program, which is listed on the first line at the left margin. 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 routine 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 controls 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 format, 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.
This switch is provided so that errors and warning messages can be turned off when ftnchek is used for purposes other than finding 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 specify options and modes of operation, rather than controlling warnings, are unaffected. These are -columns, -crossref, -include, -intrinsic, -library, -list, -makedcls, -novice, -output, -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 correctly.
Set maximum statement length to num columns. (Beyond this is ignored.) This setting is provided to allow checking of programs 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 processed. 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.
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 keyword 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 keywords with their meanings are as follows:
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 undefined 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.
Prints cross-reference tables. Default = none.The list consists of keywords separated by commas or colons. The keywords with their meanings are as follows:
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 listing will be given if the module contains an IMPLICIT NONE statement. Default = no.See also: -sixchar, -usage.
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.
Set the maximum number of error messages in a ``cascade''. During checking of agreement of subprogram arguments, common block declarations, and so forth, sometimes a single case will generate 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 cascade. 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 control options or the -nocheck option.
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-undefined option. The -extern switch may be retired eventually.
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 warnings are turned off.This setting provides detailed control over the warnings about supported extensions to the Fortran 77 Standard. 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 keywords 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 follows. (Further details about the extensions themselves are given below in the section on Extensions.)
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).
ACTION PAD READWRITE ADVANCE POSITION SIZE DELIM READ WRITE EORThe second group comprises the following VMS Fortran keywords:
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 statement.) The third group consists of the following IBM/MVS keyword:
NUM
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 warnings 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.
accept-type double-complex param-noparen backslash format-dollarsign 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.
This setting provides detailed control over warnings about standard 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 warnings 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.
See also: -f77, -f90, -portability, -pretty, -style, -wordsize.
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.
See also: -novice, -version, and help option of all settings that take a list of keywords.
Define non-alphanumeric characters that may be used in identifiers. 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 dollar 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 identifiers containing these characters in implicit typing.
See also: -source.
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.
Controls whether ftnchek recognizes certain nonstandard intrinsic functions as intrinsic. The list consists of keywords separated 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.
CDABS CDSQRT DREAL ZLOG CDCOS DCMPLX IMAG ZSIN CDEXP DCONJG ZABS ZSQRT CDLOG DIMAG ZEXP ZCOS CDSINThe 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 SNGLQThe keywords controlling recognition of other nonstandard intrinsic functions are as follows:
BTEST IBCLR IEOR ISHFTC EXIT IBITS IOR LOC IAND IBSET ISHFT NOT
ABORT GMTIME LTIME SRAND AND IARGC OR SYSTEM GETARG IRAND RAND TIME GETENV LSHIFT RSHIFT XOR
DATE IDATE SECNDS TIME ERRSNS RAN SIZEOF
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 determines 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 functions. The non-standard warnings are controlled by the -f77=intrinsic option.
The default value of this setting is equivalent to -intrinsic=all followed by -intrinsic=no-vms for the Unix version, -intrinsic=no-unix for the VMS version, and -intrinsic=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 setting 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.
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 declarations 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.
(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.
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, \-symtab, fB-quiet.
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.
PARAMETER statements are an exception to the alphabetical order rule, because the Fortran 77 Standard requires that the expressions 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 declaration files.
Explicit declaration of all variables is considered good modern programming practice. By using compiler options to reject undeclared variables, misspelled variable names (or names extending past column 72) can be caught at compile time. Explicit declarations also greatly facilitate changing floating-point precision 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 Fortran 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 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, -makedcls is equivalent to -makedcls=declarations (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:
The ftnchek distribution includes a program, dcl2inc, which processes declaration files to produce files containing declarations 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.
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.
This flag is intended to provide more helpful output for beginners. It has two effects:Default = yes.
- (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 function 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.
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 subprogram parameter.
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 produce warnings for supported extensions to the Fortran 77 Standard, 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 keywords: 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 -noportability is equivalent to -portability=none. The warning keywords with their meanings are as follows:
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 keyword 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 explanation 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:
See also: -f77, -portability, -style.
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 -noproject is equivalent to -project=none. The keywords with their meanings are as follows:
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.
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 functions 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.
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.
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 modules. 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.
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 allocated in chunks of this size. The following is an explanation of the items printed:
One of the goals of the ftnchek program is to help users to write portable Fortran programs. One potential source of nonportability is the use of variable names that are longer than six characters. Some compilers just ignore the extra characters. 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.
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. Routines 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.
This setting controls certain options about the form of the Fortran 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:
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 backslash 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 apostrophe or quote mark in a string instead of using the standard mechanism of doubling the delimiter; (b) the backslash is used to escape the end-of-line in order to continue 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.
Note that this implicit typing is treated as equivalent to an explicit type declaration for the parameter. Therefore, if you use -makedcls=undeclared-only to generate declarations only of undeclared variables, these parameters will not be included.
See also: -f77, -include, -portability.
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 complained 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:
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.
See also: -calltree, -crossref, -list, -reference, -sort, -vcg.
Warn about possible truncation (or roundoff) errors. Most of these are related to integer arithmetic. By default, all warnings are turned on.This setting provides detailed control over the warnings about possible truncation 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 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 equivalent to -truncation=all, and -notruncation is equivalent to -truncation=none. The warning keywords with their meanings are as follows:
See also: -portability, -wordsize.
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 warning. 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:
See also: -common, -declare, -extern, -library.
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 created as a subgraph nested inside its calling routines. This allows you to interactively display subgraphs or summarise them.
xvcg is a graph visualisation tool which runs under the X windows 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.
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.
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.
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-conforming 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.
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 PRECISION.
See also: -pointersize, -portability, -truncation.
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 preferences file containing options and settings. It will search in the following 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.
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 precision 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 checking. 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 separate source file. If each source file may contain more than one subprogram, 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 possible 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 status of COMMON blocks and COMMON variables according to the -usage setting. 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 different 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 directories, 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' -exec ftnchek -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.prjThen a program source file can be checked by using the command
ftnchek prog.f ... -lib ourlib.prjand 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.
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.2 November 2002 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 18 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 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 corresponding 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:
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!
``Error'' means a syntax error. The simplest kind of syntax errors are typographical errors, for example unbalanced parentheses or misspelling of a keyword. This type of error is caught by the parser and appears with the description ``parse error'' or ``syntax error'' (depending on whether the parser was built using GNU bison or UNIX yacc respectively). This type of error message cannot be suppressed. Be aware that this type of error often means that ftnchek has not properly interpreted the statement where the error occurs, so that its subsequent checking operations will be compromised. You should eliminate all syntax errors before proceeding to interpret the other messages ftnchek gives.
``Warning: Nonstandard syntax'' indicates an extension to Fortran that ftnchek supports but that is not according to the Fortran 77 Standard. The extensions that ftnchek accepts are described in the section on Extensions 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 conditions are legal under the standard. Some are illegal but do not fall under the heading of syntax errors. Usage errors are one example. These refer to the possibility that a variable may be used before it has been assigned a value (generally an error), or that a variable is declared but never used (harmless but may indicate carelessness). The amount of checking for usage errors is controlled by the -usage flag, which specifies the maximum amount of checking by default.
Truncation warnings cover situations in which accuracy may be lost unintentionally, for example when a double precision value is assigned to a real variable. These warnings are controlled by the -truncation setting, which is on by default.
``Nonportable usage'' warns about some feature that may not be accepted by some compilers even though it is not contrary to the Fortran 77 Standard, or that may cause the program to perform differently on different platforms. For example, equivalencing real and integer variables is usually a non-portable practice. The use of extensions to the standard language is, of course, another source of non-portability, but this is handled as a separate case. To check a program for true portability, both the -portability and the -f77 flags should be used. They are both turned off by default. The -wordsize setting is provided to check only those nonportable usages that depend on a particular machine wordsize.
``Possibly misleading appearance'' is used for legal constructions that may not mean what they appear to mean at first glance. For example, Fortran is insensitive to blank space, so extraneous space within variable names or the lack of space between a keyword and a variable can convey the wrong impression to the reader. These messages can be suppressed by turning off the -pretty flag, which is on by default.
Other messages that are given after all the files are processed, and having to do with agreement between modules, do not use the word ``warning'' but generally fall into that category. Examples include type mismatches between corresponding variables in different COMMON block declarations, or between dummy and actual arguments of a subprogram. These warnings are controlled by the -common and -arguments settings respectively. By default both are set for maximum strictness of checking.
Another group of warnings about conditions that are often harmless refer to cases where the array properties of a variable passed as a subprogram argument differ between the two routines. For instance, an array element might be passed to a subroutine that expects a whole array. This is a commonly-used technique for processing single rows or columns of two-dimensional arrays. However, it could also indicate a programming error. The -array setting allows the user to adjust the degree of strictness to be used in checking this kind of agreement between actual and dummy array arguments. By default the strictness is maximum.
``Oops'' indicates a technical problem, meaning either a bug in ftnchek or that its resources have been exceeded.
The syntax error messages and warnings include the filename along with the line number and column number. ftnchek has two different options for the appearance of these error messages. If -novice is in effect, which is the default, the messages are in a style approximating normal English. (In default style, the filename is not printed in messages within the body of the program if -list is in effect.) The other style of error messages is selected by the -nonovice option. In this style, the appearance of the messages is similar to that of the UNIX lint program.
ftnchek is still blind to some kinds of syntax errors. The two most important ones are detailed checking of FORMAT statements, and almost anything to do with control of execution flow by means of IF, DO, and GOTO statements: namely correct nesting of control structures, matching of opening statements such as IF ... THEN with closing statements such as ENDIF, and the proper use of statement labels (numbers). Most compilers will catch these errors. See the section on Limitations for a more detailed discussion.
If ftnchek gives you a syntax error message when the compiler does not, it may be because your program contains an extension to standard Fortran which is accepted by the compiler but not by ftnchek. (See the section on Extensions.) On a VAX/VMS system, you can use the compiler option /STANDARD to cause the compiler to accept only standard Fortran. On most UNIX or UNIX-like systems, this can be accomplished by setting the flag -ansi.
Many of the messages given by ftnchek are self-explanatory. Those that need some additional explanation are listed below in alphabetical order.
COMMON /COM1/ A,B and COMMON /COM1/ A(2)
NOTE: This message means that the affected statement is not interpreted. Therefore, it is possible that ftnchek's subsequent processing will be in error, if it depends on any matters affected by this statement (type declarations, etc.).
SUBROUTINE SUBA(X) REAL Xand elsewhere invokes SUBA by
CALL SUBA(2)
CALL SUBA(2.0)
When checking an argument which is a subprogram, ftnchek must be able to determine whether it is a function or a subroutine. The rules used by ftnchek to do this are as follows: If the subprogram, besides being passed as an actual argument, is also invoked directly elsewhere in the same module, then its type is determined by that usage. If not, then if the name of the subprogram does not appear in an explicit type declaration, it is assumed to be a subroutine; if it is explicitly typed it is taken as a function. Therefore, subroutines passed as actual arguments need only be declared by an EXTERNAL statement in the calling module, whereas functions must also be explicitly typed in order to avoid generating this error message. Controlled by -arguments setting.
This warning is not affected by the -arguments setting.
INTEGER FUNCTION COUNT(A)and invokes COUNT in another module as
N = COUNT(A)
INTEGER COUNT
Given for -arguments setting 2 or 3.
-------------------------------------------------------- | | implicit | parameter |--------------------- | | other specification format |---------------|--------------------- and | | statement-function entry | data |--------------------- | | executable -------------------------------------------------------- Table 1
ftnchek uses only one line of lookahead when analyzing a program into its basic syntactic elements. If a particular statement is difficult to identify, it may be handled improperly if the ambiguity is not resolved on a single line. This limitation applies to complex constants except in DATA statements, and to situations in which a variable name might be confused with a keyword. For example, if the variable name WRITE is used for an array, then a very long statement assigning a value to some element of this array could be mistaken as a WRITE statement if the equals sign is not on the same line as the word WRITE.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.
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, recognition 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.
All of these extensions (except lower-case characters) will generate 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 contain UNIX-style backslash escape sequences. They will be interpreted as such if the -source=unix-backslash setting 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 traditional fixed format. (F90)
A semicolon is allowed as a statement separator. (F90)
Lower case characters are permitted, and are converted internally 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 Fortran 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 setting -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 -identifier-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 directives, 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 directives 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.
Statements may have any number of continuation lines. The Fortran 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 permitted. (F90)
NAMELIST I/O is supported. The syntax is the same as in Fortran 90.
FORMAT statements can contain a dollar sign to indicate suppression 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, corresponding 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 Fortran 77 Standard allows a length specification only for CHARACTER data.
ftnchek supports the DOUBLE COMPLEX type specification for a complex quantity whose real and imaginary parts are double precision. Mixed-mode arithmetic involving single-precision complex with double-precision real data, prohibited under the Standard, 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 standard 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 distribution 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 provided. 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 location 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 functions.) 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.
We especially want to know if ftnchek crashes for any reason. It is not supposed to crash, even on programs with syntax errors. Suggestions 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 extensions 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 documented in either place, then send a report including
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.
WRITE(5,*) (A(J), J=1,10)
Prognosis: A future version of ftnchek is planned which will handle implied-do loops correctly.
Prognosis: To be fixed in a future version of ftnchek.
Prognosis: unlikely to be fixed.
Prognosis: may be fixed someday.
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 University 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 University were extremely helpful as alpha testers. We also thank Jack Dongarra for putting ftnchek into the netlib library of publicly available software.
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 systems, 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.fordham.edu/~ftnchek . For further information and to report bugs, you may contact Dr. Robert Moniot at the following address: