Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!hc!beta!jlg
From: jlg@beta.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: fortran lint?
Message-ID: <20089@beta.UUCP>
Date: 9 Jun 88 00:04:40 GMT
References: <3835@pasteur.Berkeley.Edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 58

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