Bugs

ftnchek still has much room for improvement. Your feedback is appreciated. 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. 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

The operating system and CPU type on which ftnchek is running.
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.)
A brief description of the bug.
If possible, a small sample program showing the bug.

The report should be sent to the following address: moniot@fordham.edu

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.

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 handle implied-do loops correctly.
Bug: Variables used (not as arguments) in statement-function subprograms do not have their usage status updated when the statement function is invoked.
Prognosis: To be fixed in a future version of ftnchek .
Bug: VAX version does not expand wildcards in filenames on the command 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.
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.

Next: Acknowledgements