1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
DCL2INC(1) DCL2INC(1)
NAME
dcl2inc - postprocess ftnchek .dcl files to create sepa-
rate INCLUDE files
SYNOPSIS
dcl2inc *.dcl
DESCRIPTION
dcl2inc postprocessing declaration files output by
ftnchek(1), replacing unique COMMON block definitions by
Fortran INCLUDE statements. For each input .dcl file, a
modified output .dcn file is produced, together with
include files named by the COMMON block name, with file-
name extension .inc.
In addition, dcl2inc produces on stdout a list of Makefile
dependencies for the UNIX make(1) utility. These can be
appended to the project Makefile to ensure that any subse-
quent changes to .inc files provoke recompilation of
source files that include them.
dcl2inc warns about COMMONs which differ from their first
occurrence, and simply copies them to the output .dcn
file, instead of replacing them with an INCLUDE statement.
Thus, any COMMON statements that are found in the output
.dcn files should be examined carefully to determine why
they differ: they may well be in error.
Replication of identical data, and bugs arising from sub-
sequent modification of only part of it, is a significant
reason why Fortran programming projects should require
that COMMON declarations occur in separate include files,
so that there is only a single point of definition of any
global object.
Even though the Fortran INCLUDE statement was tragically
omitted from the 1977 Standard, it has long been imple-
mented by virtually all compiler vendors, and is part of
the 1990 Standard. In practice, there is therefore no
portability problem associated with use of INCLUDE state-
ments, provided that one avoids nonportable file names.
As long as the code obeys Fortran's limit of six-character
alphanumeric names, the filenames generated by dcl2inc
will be acceptable on all current popular operating sys-
tems.
Fortran's default, or IMPLICIT, variable typing is depre-
cated in modern programming languages, because it encour-
ages sloppy documentation, and worse, bugs due to mis-
spelled variables, or variables that have been truncated
because they extend past column 72. If all variables used
are explicitly typed, and a compiler option is used to
reject all program units with untyped variables, variable
spelling and truncation errors can be eliminated.
Version 1.00 12 March 1995 1
DCL2INC(1) DCL2INC(1)
Variable declarations that have been produced automati-
cally by a tool like ftnchek(1) or pfort(1) have a consis-
tent format that facilitates application of stream editors
(e.g. to change array dimensions or rename variables), and
simple floating-point precision conversion tools like
d2s(1), dtoq(1), dtos(1), qtod(1), s2d(1), and stod(1).
CAVEAT
The current version (2.9) of ftnchek(1) does not produce
Fortran EQUIVALENCE statements in .dcl files, so you must
be careful to preserve them when replacing original decla-
rations with new ones from .dcl or .dcn files.
SEE ALSO
d2s(1), dtoq(1), dtos(1), ftnchek(1), make(1), pfort(1),
qtod(1), s2d(1), stod(1).
AUTHOR
Nelson H. F. Beebe, Ph.D.
Center for Scientific Computing
Department of Mathematics
University of Utah
Salt Lake City, UT 84112
Tel: +1 801 581 5254
FAX: +1 801 581 4148
Email: <beebe@math.utah.edu>
Version 1.00 12 March 1995 2
|
