jlg@beta.UUCP (Jim Giles) (06/09/88)
In article <3835@pasteur.Berkeley.Edu>, wan@cory.Berkeley.EDU (Hank S. Wan) writes: > if FORTRAN is so great as in all the "RE: Should I convert FORTRAN code to C" > somebody must have a type checker so the following is not merrily accepted > by unix f77. > > PROGRAM bar > j = sub1( i ) > PRINT *, i, j > END > > > SUBROUTINE sub1( r ) > r = 1.0 > END > > lint would do the job for c code. (and NO, lint is not a hassle if you're > smart enough to use it often, and interpret the results right.) > Checking consistency in type is useful for any large project in any serious > language. The language you code in has a remarkable effect on the above example. Fortran is required to allow seperate compilation. Most compilers will not notice the above as a problem. If the program and the subroutine are seperately compiled, ther is NO WAY for the compiler to notice the problem. Some programmers take non-standard advantage of the way their local Fortran handles this to do some sneaky things (I have often declared things as functions even when some of its references were as subroutines - I know that in my environment the calls are implemented identically except that the subroutine linkage ignores the functional result). Some people even like the implicit type switching involved here (Fortran requires reals and integers to occupy the same size 'machine storage unit' - the type switching here is fairly portable). The C version of the above will usually work just as the Fortran version did. LINT will identify this as a problem, but only if the two routines are in the same file. Seperately compiled, even LINT won't find this error. The ADA version of this code will produce an 'unsatisfied external' message. SUB1 is assumed to be overloaded. The call will be matched only to a version of the SUB1 procedure which has the right attributes and the same number of same typed arguments. A similar problem (in this newsgroup) was recently cited. Fortran will (or should) generate an error for SQRT(5) since the argument isn't real. C will not generate an error (not even from LINT - SQRT is seperately compiled). In fact, C will probably take the square root of whatever real has the same bit configuration as the integer 5. This behaviour was cited as a strength of C by some responses. This strange set of behaviours is really a result of the different philosophies of each of the languages involved. I can't see that any of this discussion shows a _weakness_ in any of the languages (since the behaviour of each is denigrated by some and praised by others). J. Giles Los Alamos
hutchson@convex.UUCP (06/09/88)
The Honeywell(-Bull) GCOS Fortran-77 compiler has an option to check argument and result types of subprograms at runtime. For static calls (which constitute the large majority), the full check is only done the first time the routine is called; for calls to routines that are formal arguments, the full check is done each time. The full check includes: - Number, type, and (for characters) length of arguments - Presence of result, and (if present) type (and possibly length) - Number of alternate returns - Possible assignment to expressions or constants (warning only) For large programs that were submitted as examples of compiler errors, we routinely compiled with this and subscript range checking. Nearly always immediately found a user error, too.
johnl@ima.ISC.COM (John R. Levine) (06/10/88)
In article <20089@beta.UUCP> jlg@beta.UUCP (Jim Giles) writes: >Fortran is required to allow seperate compilation. Most compilers will >not notice the above as a problem. If the program and the subroutine >are seperately compiled, ther is NO WAY for the compiler to notice >the problem [of mismatched function arguments]. Not true at all. I have used systems in which the compiler places into object files information about argument types, and the linker can report mismatches. Certainly, 98% of existing linkers don't do this, but it's not all that hard to arrange and I expect that as CASE environments become better accepted you'll find this kind of cheking more often. As with all useful type checking systems, there are escapes for old code that cheats. [Later on Mr. Giles notes that Ada does exactly this kind of check, and an entry and a call match only if the name and also the arguments match.] >The C version of the above will usually work just as the Fortran version >did. LINT will identify this as a problem, but only if the two routines >are in the same file. Seperately compiled, even LINT won't find this >error. You must have a really weak version of lint. All of the lints I've ever used create a file full of type info for each source file you lint, then merge them all together and report inter-routine and inter-module type matching problems. More to the original point, I haven't seen any Fortran lints, though they'd surely be useful. Does PFORT do any inter-procedure checking? -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw
vern@h2opolo.ee.lbl.gov (Vern Paxson) (06/10/88)
In article <20089@beta.UUCP> jlg@beta.UUCP (Jim Giles) writes: >.... LINT will identify this as a problem, but only if the two routines >are in the same file. Seperately compiled, even LINT won't find this >error. >.... Fortran will >(or should) generate an error for SQRT(5) since the argument isn't real. >C will not generate an error (not even from LINT - SQRT is seperately >compiled). Just to keep the record straight, lint works on multiple files (and libraries) and will find both of the bugs which Jim mentions. Vern Paxson vern@lbl-csam.arpa Real Time Systems ucbvax!lbl-csam.arpa!vern Lawrence Berkeley Laboratory (415) 486-6411 Vern Paxson vern@lbl-csam.arpa Real Time Systems ucbvax!lbl-csam.arpa!vern Lawrence Berkeley Laboratory (415) 486-6411
jlg@beta.UUCP (Jim Giles) (06/14/88)
In article <1059@ima.ISC.COM>, johnl@ima.ISC.COM (John R. Levine) writes: > In article <20089@beta.UUCP> jlg@beta.UUCP (Jim Giles) writes: > > [...] If the program and the subroutine > >are seperately compiled, ther is NO WAY for the compiler to notice > >the problem [of mismatched function arguments]. > ^^^^^^^^ > Not true at all. I have used systems in which the compiler places into object > files information about argument types, and the linker can report mismatches. This seems like exactly what I said: The COMPILER can't check! I have maintained both compilers and loaders on LANL Crays and have recommended this type of check for years. The present (and historical) compiler output tables had no place for the info and Cray didn't (until recently) see the need for it. The new tables have the space for this info and I am looking forward to some future loader which actually does the check. > [...] > >The C version of the above will usually work just as the Fortran version > >did. LINT will identify this as a problem, but only if the two routines > >are in the same file. Seperately compiled, even LINT won't find this > >error. > > You must have a really weak version of lint. All of the lints I've ever used > create a file full of type info for each source file you lint, then merge ^^^^^^^^^^^^^^^^ > them all together and report inter-routine and inter-module type matching > problems. Possibly so, but I was talking about SEPERATELY COMPILED code. If you have all the sources you can clearly do LINT on the concatenated sum of all the source files (which is probably what happens when you say: lint file1 file2 ...) Seperately compiled usually means that the compile is being performed in the absence of other source (the rest of the code is, or will be, available ONLY as '*.o' files). Lint is of little help in this case. J. Giles Los Alamos
jerry@violet.berkeley.edu ( Jerry Berkman ) (06/15/88)
In article <20282@beta.UUCP> jlg@beta.UUCP (Jim Giles) writes: >In article <1059@ima.ISC.COM>, johnl@ima.ISC.COM (John R. Levine) writes: >> >> I have used systems in which the compiler places into object >> files information about argument types, and the linker can report mismatches. > >This seems like exactly what I said: The COMPILER can't check! IBM's VS FORTRAN compiler can check. E.g.: FORTVS UTILS ( ICA(UPDATE(UTILDEC))) compiles the source in UTILS FORTRAN creating binary UTILS TEXT and creating UTILDEC ICA which has all the declaration info in an internal format. Then if you compile further source by: FORTVS PROG ( ICA(USE(UTILDEC))) all calls in PROG are checked against the subroutine declarations stored in UTILDEC ICA. In this manner, a vendor can supply object and ICA files without supplying source, and VS FORTRAN can check usage across separate compiles. It checks number and type of arguments, number of dimensions of an array argument, etc. I hope to see similar tools come out of TOOLPACK and from other FORTRAN compiler vendors in the future. >Seperately compiled usually means that the compile >is being performed in the absence of other source (the rest of the code >is, or will be, available ONLY as '*.o' files). Lint is of little >help in this case. > >J. Giles >Los Alamos The "-C" option of lint creates "lint libraries" so that separately compiled C procedure calls can be checked against C procedure declarations in the absence of source. - Jerry Berkman Computing Services, U.C. Berkeley, (415)642-4804 jerry@violet.berkeley.edu
jlg@beta.lanl.gov (Jim Giles) (06/16/88)
In article <10947@agate.BERKELEY.EDU>, jerry@violet.berkeley.edu ( Jerry Berkman ) writes: > [...] > IBM's VS FORTRAN compiler can check. E.g.: > FORTVS UTILS ( ICA(UPDATE(UTILDEC))) > [...] > FORTVS PROG ( ICA(USE(UTILDEC))) > [...] > The "-C" option of lint creates "lint libraries" so that separately > compiled C procedure calls can be checked against C procedure declarations > in the absence of source. I knew about the -c option on lint. However, I only knew because I looked up lint before my last article. I suspect you did the same. In both the above cases, the sources must be compiled or run through some processor with special extra operations. As a practical matter, no one ever ships a subroutine library with the appropriate 'lint library' (or its IBM equivalent). When someone sends you a dot-oh file, that's all you get. A feature that no one uses might as well not exist. J. Giles Los Alamos P.S. This is not to say that I don't agree with you. The 'lint library' type of information SHOULD be in the dot-oh file (not separately). It should be there by default - you should not be able to turn it off. Also, the appropriate tool to do the final checking is the loader (not the compiler as in the IBM example above).
FRI@cup.portal.com (06/18/88)
>WANTED: a FORTRAN type checker.
Information Processing Techniques has a program called FORTRAN-lint,
which does source code checking (including parameter and other global
program checking). I do not know if this product is ported to UNIX, as
our copy is for AOS. For further information, contact:
Information Processing Techniques Corporation
1096 East Meadow Circle
Palo Alto, CA 94303
(415) 494-7500
Please note that I am in no way connected to IPT, other than as a
user of their product.
Hope this is of help.
Paul Floriani:Foothill Research Inc./1301 Shoreway Rd. Suite 300/Belmont,CA
FRI@cup.portal.com or {sun|sun.com|sun!portal}!cup.portal.com!FRI 94002
Go, lemmings, go!...Disclaimer:Views, opinions above my own. <inhale!>