does lint for fortran exist?
Rob Kutschke
We recently dusted off an old piece of software which has served us
reliably on IBM mainframes and on assorted VMS VAXen. The original
authors were careless about passing the correct argument types.
In particular they frequently passed REAL*8 variables into
routines which expected REAL*4. This, of course, causes no end
of trouble on a box with IEEE floating point representations, such
as our recently purchased DECstation.
So, the question is:
Does anyone have a beast which scans fortran source and
flags this sort of problem. Perhaps a "lint" for fortran.
Rob
--
kuts...@oldkat.physics.utoronto.ca (internet) Rob Kutschke
kutschke@utorphys (bitnet) University of Toronto
(416) 978-6632 (phone) Department of Physics
(416) 978-8221 (fax) Toronto, Ont. M5S 1A7
Harald Anlauf
Rob> We recently dusted off an old piece of software which has served us
Rob> reliably on IBM mainframes and on assorted VMS VAXen. The original
Rob> authors were careless about passing the correct argument types.
Rob> In particular they frequently passed REAL*8 variables into
Rob> routines which expected REAL*4. This, of course, causes no end
Rob> of trouble on a box with IEEE floating point representations, such
Rob> as our recently purchased DECstation.
Rob> So, the question is:
Rob> Does anyone have a beast which scans fortran source and
Rob> flags this sort of problem. Perhaps a "lint" for fortran.
There is a program by Robert Moniot, called "forchek". We now have version 2.4,
and it works well under Unix and should work under VMS.
I found it in net...@research.att.com, but you might contact the
author (MON...@FORDMULC.BITNET, mon...@mary.fordham.edu).
--
-ha
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harald Anlauf | Phone: +49-6151-16-2972 (office)
TH Darmstadt | +49-6151-714673 (private)
Schlossgartenstr. 9 | Fax: +49-6151-16-4321
D-6100 Darmstadt | Internet: anl...@crunch.ikp.physik.th-darmstadt.de
Germany | Bitnet: td...@ddagsi3.bitnet
T.R.Hopkins
>
>We recently dusted off an old piece of software which has served us
>reliably on IBM mainframes and on assorted VMS VAXen. The original
>authors were careless about passing the correct argument types.
>In particular they frequently passed REAL*8 variables into
>routines which expected REAL*4. This, of course, causes no end
>of trouble on a box with IEEE floating point representations, such
>as our recently purchased DECstation.
>
>So, the question is:
>
>Does anyone have a beast which scans fortran source and
>flags this sort of problem. Perhaps a "lint" for fortran.
>
> Rob
>
We have three such tools on site
1) QA-Fortran from Programming Research Ltd,
Waynflete House,
74-76 High Street
Esher, Surrey KT10 9QS, UK
This performs a full static analysis of Fortran code for adherence to
the Fortran 77 Standard; it also checks argument passing to
subprograms for type and number and takes account of direction of
passing. It also provides a number of complexity metric values which
have proved very useful in identifying code likely to be a
maintenance problem. Calling trees are also provided.
It is available on most systems supporting a C compiler (certainly
VMS and SUNs -- we run it on both of these). There is a nice X
interface available if you are running on a workstation -- I think a
DEC-Windows version is in the pipeline.
2) FORCHECK from Polyhedron Software Ltd.,
Magdalen House
98 Abingdon Road,
Standlake, Witney,
OX8 7RN, UK
This performs most of the static checks QA-Fortran performs -- I
don't think it is a thorough on inter-module checks but it still does
a good job. Calling trees are also provided. There are no complexity
metrics.
This one is written in Fortran and is available on many platforms.
3) TOOLPACK from NAG Ltd,
Wilkinson House,
Jordan Hill Road,
Oxford, OX2 8DR, UK.
This is public domain s/ware -- you just pay a distribution fee
although if you pay a bit more (around Pounds UK 200) you can get a
number of machine specific versions. This package contains a large
number (50+) of Fortran tools including precision transformers,
pretty printers etc.
On the static analysis side there is a verifier tool which performs
many of the static checks that the two tools above perform.
Unfortunately, due to the way Toolpack works, the final output is
just a list of error messages -- you have to match them back to the
source; QA-Fortran and FORCHECK both have their errors in with a
source listing or as soon as possible in the case of inter module
checks.
There is a separate tool which produces call trees.
The whole tool-kit is written in Fortran 77; a C interface is
available for the interface to the operating system.
These tools have saved us an enormous amount of heartache and located
a number of difficult bugs -- I certainly wouldn't want to go back to
the dark ages when we didn't have such aids for Fortran!!
Hope this helps,
Tim
Greg Lindahl
>
>reliably on IBM mainframes and on assorted VMS VAXen. The original
>authors were careless about passing the correct argument types.
>In particular they frequently passed REAL*8 variables into
>routines which expected REAL*4. This, of course, causes no end
>of trouble on a box with IEEE floating point representations, such
>as our recently purchased DECstation.
You can detect problems like this using some odd contortions:
1) run the source through f2c, the fortran-to-c converter, to ANSI C
2) edit the C file to include the prototype file
3) run through gcc
4) watch the errors fly.