Path: utzoo!mnetor!uunet!husc6!think!ames!lll-tis!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN horrors
Message-ID: <835@cresswell.quintus.UUCP>
Date: 30 Mar 88 07:09:31 GMT
References: <497@amethyst.UUCP>
Distribution: na
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 40

In article <497@amethyst.UUCP>, chris@spock (Chris Ott) writes:
> lamaster@ames.arpa (Hugh LaMaster) writes:
> > Fortran replacement it is hopeless.  The syntax is confusing and more error
> > prone than Fortran, but even worse, because C doesn't have dynamic array
> > dimensioning you can't use it for separately compiled libraries like
> > Linpack.
> 
>      When was the last time you programmed in C? If I remember correctly, C
> does have dynamic array dimensioning.

K&R C hasn't got dynamic array dimensioning, and neither has dpANS C,
but the GNU C compiler from the Free Software Foundation.
However, see the book "Numerical Algorithms in C", which is now out.
I regard the techniques they use as unpleasant hacks, but you _can_ get
the job done.

> > of Fortran programmers have run Linpack programs on their machines with
> > no modifications.  And thousands of C programmers continue to write code
> > which depends on the existence of data types of certain sizes ( e.g. 16 bit
> > ints), on machine dependencies such as byte order, and indeed on how the
> > compiler will allocate the fields in a structure (just like the infamous
> > Fortran equivalence!)...

Writing numerical code that will run under a variety of machines is not a
trivial problem in any language.  You might like to look at the ELEFUNT
package.  I have seen source code for a couple of statistics packages
written in Fortran, and they made their code "portable" by writing their
own equivalent of C's preprocessor.
Much of the portability of Linpack comes from riding on the back of the Basic
Linear Algebra Subroutines, so that a lot of nasty machine-dependent stuff
(much of the actual numerical computations) is concealed.

> WRITE, and CLOSE were the same. Even the I/O itself isn't done the same: Sun
> Fortran is the only one I know that writes the record length at the beginning
> and the end of an unformatted record.

In the B6700 MCP, this was FILETYPE=6 ("Fortran Linkword").  I thought it
was fairly common: how else are you supposed to be able to seek in such a
file?  With the size at each end of the record, you can move forwards AND
backwards a record at a time.