|
When WinFPT reads the code it checks the syntax of each individual statement. We are now
going to run checks between statements and between subroutines.
Dismiss the Error Table and Symbol Table, and click on Check on the main menu. The available
checks are listed in the Check drop-down menu.
Arguments
Select Arguments... from the drop-down menu.
WinFPT displays a menu of options for the argument check. Accept the defaults by clicking on
OK. The report is displayed in the Report view. Inconsistent arguments are reported for two
routines.
WinFPT shows the sub-program declaration statement, and then the statements where the
arguments are inconsistent. The attributes of the inconsistent arguments are tabulated with the
formal arguments (the argument in the sub-program code) on the left and the actual arguments
passed in on the right. The inconsistent attributes are marked by *** on the right of the table.
Scroll down to the first inconsistency, argument 4 in CLOSAP.
The problem here is that the formal argument, CRITA, is declared to be REAL, and the actual
argument, ALTCR is declared to be REAL*4. The characters df following the data size of
CRITA indicates that the size is inferred from the system defaults.
This is not an error because the default size of a REAL number on the PC is 4 bytes. The
argument will be passed as intended. But if the code were run on a machine with a default REAL
size of 8 or 16 bytes the program would not work.
Suppose that we are only concerned with things which will cause errors on the current system.
We can tell WinFPT to ignore the issue of default data sizes. Select the menu item Check |
Arguments... again. This time, un-check the Check default sizes box and run the check again.
WinFPT only reports one routine with inconsistent arguments.
The integer parameter MSCLIM, which we have seen already, has been passed into DEVIAT
which expects a REAL. The bit pattern of the integer value 3 will be read as if it were a real
number, and with the IEEE numbers on a PC will have a value very close to zero.
The report shows the file and line number where the error occurs. It is in milatc.for at line 91. To
examine the code, double-click MILATC.FOR in the project tree window. The file is displayed in
the code window. The original source line numbers are shown on the left. Scroll down to line 91.
WinFPT has marked the problem with an error message.
C1 is the mean climb, MMCLIM, plus a random deviate with standard error MSCLIM. MSCLIM
will be read as zero, so this term in the expression for C1 has been lost.
WinFPT can correct errors like this automatically. Select the software engineering button on the
main toolbar.
or select the menu item Tools | Software Engineering ....
Select the Arguments tab and check Correct inconsistent arguments.
Click Apply and dismiss the window. The code at line 91 has now been changed, and there is a
new message, marking the change.
WinFPT has corrected the error at the call-site. The integer MSCLIM has been converted
explicitly to a real number with the intrinsic function REAL.
Checking Names
Fortran compilers do not know that the names used for variables mean anything. In
particular, they cannot recognise that the same name used for two different variables in different
sub-programs may be intended to refer to the same object.
WinFPT checks that names are used consistently in different sub-programs. For example, an
inconsistency is reported if the same name is used for two different COMMON block addresses,
or for Fortran parameters with two different values. To run the check, select the menu item
Check | Names.... A dialog box appears showing filters for the check. Accept the defaults by
clicking on OK. The results of the check are written in the Report view..
WinFPT reports inconsistent use of 6 names. The first is BEAR1, which is a local variable in the
main program, MILATC, and a variable in a COMMON block in the subroutine PATHS. Should
they really be the same?
To investigate BEAR1, open the symbol table by clicking on the button on the toolbar:
Check the Show all symbols box. Check that the current Search scope is All files. It is
selected in the panel below the Project Tree. Click on the instance of BEAR1 in MILATC in the
symbol table. The code window displays the first occurrence, which is the declaration. Click the
Find and Next buttons on the symbol table to examine all of the occurrences. BEAR1 is assigned once and
used three times. It all looks perfectly reasonable.
Click on the instance of BEAR1 in PATHS. Again, use the Find and Next buttons to see the
occurrences. Note that WinFPT searches all of the files for the COMMON block variable. There
are three occurrences, but apparently BEAR1 is never assigned. To check this, click on the Find
Assigs button. WinFPT searches the entire code for any situation where BEAR1 could be
assigned. It displays direct assignments, assignments to variables which are equivalenced to
BEAR1 and assignments to objects which share the same memory in the COMMON block. For
BEAR1 it reports Not in search scope. There are none!
BEAR1 is in a COMMON block. To see what has happened, WinFPT can display the COMMON
block organisation. Select the menu item Report | COMMON Blocks.
A listing of the variables in COMMON blocks is displayed in the report window. The listing is
arranged in address order.
Scroll down to the variable BEAR1. The usage of each variable is displayed in the right-hand
column. BEAR1 is marked as read, but never written, and there is a variable named BERR1 at
the same address, declared only in MILATC, which is unused.
Click on BERR1 in the symbol table. Now we can see what is going on. The COMMON block
declaration of BEAR1 in MILATC has been mis-spelled. BEAR1 is therefore not in the COMMON
block, and the variable in PATHS never receives a value.
The Name Check report in the Report view has been overwritten by the COMMON block listing.
Select the menu item Check | Names to restore it.
The second inconsistent name is CPATH. This is used for an array in MILATC and in PATCOM.
The arrays are both REAL*4, they have the same COMMON block address and the same array
bounds. They differ in that CPATH in PATHS is declared explicitly to be REAL*4 but CPATH in
MILATC is declared REAL with no data size specification. The data size comes from the system
defaults. This is the meaning of the annotation df following the data size in the report.
This is a bug waiting to happen.
If this code were moved to a system where the default real size were 8 bytes, the two arrays
would no longer occupy the same memory. If we are only going to run this program under Win32,
the difference in declarations will not matter. As with the argument check, we can filter out these
reports. Run the name check again, and un-check the Check default size box in the filter menu.
The report for CPATH disappears.
There are now 4 names used inconsistently. We already know about BEAR1. In the remaining
cases, DT, I and NSTEP, a name has been used for a local variable in one routine and as a
formal argument in another. This is quite common practice and does not usually indicate a
problem. WinFPT can filter these reports out. Re-run the name check and, on the filter dialog,
un-check the box Distinguish between arguments and local variables. Now only BEAR1
remains.
Checking Usage
In the name check, we found that BEAR1 was read, but was never written to. Are there any more
errors like this one? WinFPT can check for this directly.
Select the menu item Check | Usage. WinFPT checks for variables which are read but never
written, written to but never read, and declared but never used.
As expected, the report shows that BEAR1 in PATHS is read but never written to, and there are
no other variables like this. The variable THENC1, created accidentally by the mis-used keyword
THEN in MILATC is reported as written to but never read.
Checking Equivalence
The equivalence check looks for objects which occupy the same memory. WinFPT reports:
- Objects of different data types or different data sizes which are equivalenced together;
- Different objects which occupy the same memory locations in COMMON blocks without an
explicit EQUIVALENCE statement.
We know about BEAR1 and BERR1 in /PATCOM/. Are there any more?
Select the menu item Check | Equivalences.... A dialog box appears to ask whether to check or
to ignore the issue of default data sizes. On the first pass, un-check the box.
The report is written in the report window. It shows the implied equivalence of BEAR1 and
BERR1.
This is an implied equivalence because the two objects occupy the same memory, but there is no
explicit EQUIVALENCE statement. This is the only occurrence.
Repeat the check, checking the Check default sizes box. WinFPT now reports implied and
mixed (i.e. mixed data type) equivalences for MPATH and CPATH. If the program ever moves to
a 64-bit machine these will cause problems!
Formatting the Code
Unless you have already discovered the format dialog, all of the code which you have seen so far
has been written with upper case letters and very few spaces between the tokens. Perhaps this
is not your favourite style!
WinFPT completely rewrites the code, including the diagnostics which mark errors and changes,
according to rules which you specify. The code will be output to file exactly as it appears in the
code window, except that it will be a plain ASCII text file, so the syntax colouring will disappear.
Double-click the main program, MILATC, in the call-tree window. The program is displayed and
you can use it as a guide in choosing a format.
Open the formatting dialog by clicking the toolbar button:
or by selecting the menu item Tools | Format Fortran Code....
Layout:
Select the Layout tab. WinFPT writes code in Fortran 77 fixed format, Fortran 90 free
format or in tab format. Tab format is a non-standard but widely supported format in which the
label field of a line is delimited by a tab character, and continuation lines are written with a
numeric continuation character following a tab. Check that your system supports tab format
before you use it. It is supported under Compaq Visual Fortran, under all DEC operating systems
and under HP-UX and SGI Irix.
The original code was written in a mixture of Fortran 77 styles. Select each layout in turn and
view the changes in the code window. Here is a fragment of MILATC in fixed format:
The same code in tab format:
And in Fortran 90 free format. The continuation character has been defaulted to column 50 so
that it shows on the narrow screen.
Case:
Use the Case tab to select the case in which symbols, keywords, intrinsic functions and
operators are written.
Selecting As first written for symbols preserves mixed case naming conventions, so you can
name a variable, for example, SymbolTable
and the upper and lower case spelling will be preserved throughout the code.
Here is a code sample with the user-defined symbols in lower case:
Selecting Upper case for symbols with read access or symbols with write access shows how
variables are accessed. This is particularly useful when they are used as sub-program
arguments. WinFPT tracks the intent of arguments throughout the program. It uses the program
code to determine the true intent, rather than relying on INTENT statements. This is an aid in
analysing the code, rather than as a target format for the output files. For example, checking
Upper case write access:
Setting the case of file names sets the case of the names in INCLUDE statements and the case
with which they are written to the output directories. This may be important if you use disks
cross-mapped to Unix systems or boot Linux on the same machine.
Indentation:
Use the Indentation tab to specify indentation to mark control constructs and
nested declarations. You may also specify indentation for statement labels and additional
indentation for continuation lines.
The Columns to indent code box applies to Fortran 90 free format.
You can choose to indent comments to line up with the code, or to leave them as first written.
Header comments, which are comments written before the first statement other than a sub-
program or options statement, are handled independently of comments in the body of the code.
Spacing:
There are four tabs with controls for spacing.
The Spacing tab has controls for the spacing before or after different types of token. The rule
used is that a space is inserted between two token if a space is required after the first token, if a
space is required before the second token, or if the first token ends with a letter or number and
the second token begins with a letter or number. WinFPT does not insert two spaces if a space is
required after the first token and before the second. In general, it is better to control spacing
using the Space before controls rather than Space after. Otherwise spaces are sometimes
inserted before commas or other delimiters.
The three remaining spacing tabs control spaces before or after specific operators and keywords.
You can choose, for example, to write spaces either side of equals signs without affecting the
other operators and delimiters.
Here is a fragment of MILATC, with spaces before most of the tokens, lower case symbols and
free format layout:
Special:
Scroll up to the declaration section of the program code. Select the Format dialog
Special tab, and check and un-check the Column format for declarations box. In the original
file, the declarations were written as comma separated lists on one line. When Column format
for declarations is selected, WinFPT breaks them into columns so that they may be marked by
trailing comments. The Column format conditionals check box similarly formats the conditional
clauses in IF statements so that matching open parentheses are aligned vertically.
Writing the Fortran Code
To write the Fortran code to files, select the Write Fortan code button on the main toolbar.
or select the menu item Tools | Write Fortran Code... . The Generated Fortran Code dialog
opens:
Choose the output directory by browsing to
c:\program files\simcon\WinFPT\fpteg\milatc\fpt_out
This directory is empty when WinFPT is first installed. You may also need to change the primary
output file name extension to make the output visible to your compiler.
Click on Generate Fortran Files to write the code.
Now dismiss the Generated Fortran Code dialog, re-open it, and try to write the files again.
WinFPT displays a warning:
This has happened because Do not overwrite files has been selected in the Generated Fortran
Code dialog. Click on Cancel and select Overwrite CHANGED files, WinFPT will now overwrite
only those files in the output directories which have changed. This is useful if you use a makefile
because it prevents unnecessary recompilations.
Saving the Project
To save the project, click on the Save Project button on the toolbar:
or the menu item File | Save Project . WinFPT displays a dialog to request a continuation
character. The default, - will work well for Win32. You can re-load this project by double-
clicking the file, or by browsing to it from the menu item File | Open Project.
This is the end of this tutorial, but you may wish to experiment with other checks and engineering
tools. The errors in milatc are marked in the code. You may wish to correct them manually and
run the program. The results are significantly different!
And thank you for taking the time to follow the tutorial.
| 
