Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amelia!lemming.nas.nasa.gov!fouts
From: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.lang.fortran
Subject: My widget is more portable than yours (was Fortan versus C)
Message-ID: <1040@amelia.nas.nasa.gov>
Date: 23 Sep 88 00:25:53 GMT
References: <1483@valhalla.ee.rochester.edu> <4031@lanl.gov>
Sender: news@amelia.nas.nasa.gov
Reply-To: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Lines: 74

In article <4031@lanl.gov> jlg@lanl.gov (Jim Giles) writes:

>Here's a challange for you.  Port all the C utilities in UNIX system V
>to some machine which is not-at-all similar to a VAX.  I know people
>who have just done this.  Their Fortran code ported without a hitch, the
>C code had all sorts of problems.  Fortran programmers seldom make
>assumptions about wordsize, addressability, etc..  C programmers nearly
>always make such assumptions.  (I hear that YACC has a reference to 
>x[-1] in it somewhere - illegal, but oft used.)
>

This is an argument by anecdote.  Yes, it is possible to write
unportable code in C.  Yes there are examples of portable code in
Fortran.  Yes, by the way, all of the C utilities in SVR3 have been
ported to a wide range of machines, with varying degrees of effort.
Yes, I have an example of Fortran code that doesn't port very well.

(It's a commercial product.  The vendor once filed a bug report with
CDC because all common blocks weren't stored sequentially on a 205.
and because integer 0 wasn't the same as floating point zero.
It seems they were doing something like

      COMMON /BLOCK1/ A(10000), I(1000)
      COMMON /BLOCK2/ B(10000)

      DO 10 I = 1, 30000
        A(I) = 0.0
   10 CONTINUE

They were very upset when CDC wouldn't "fix" the problem.)

You can write bad code in any language and nonportable code in any
language.

There is also an argument here about portability.  One of the things
I'm currently responsible for is a benchmarking package, which among
otherthing measures i/o performance and compatibility with BSD
sockets on Unix implementations.  I started out to write a portable
code and I succeded.  It's > 10K lines of C, (several programs) and
about 6 makefiles.  It runs on every machine I've tried it on, and
I've only found a small number of portability problems.

I'm also currently responsible for a numerical library somebody else
wrote.  I have versions in C and Fortran.  The library was written by
Fortran programmers who later learned C.  The Fortran version is 6700
lines of code, the C version about 8700.  I've got the C version up
and usable on several machines.  The Fortran version doesn't port
nearly as easily.  I'm rewriting many of their assumptions about the
Fortran standard.

The conclusion I draw is *NOT* that Fortran is less portable than C,
but that I've done a good job of writing portable C and they've done a
poor job of writing portable Fortran.

The only problem I have writing K&R C which is portable is deciding
which subroutines I need to depend on.  My answer is to depend on
those common to  SVR3 and BSD 4.2 + those I can get public domain
source for.  That works for many (but not all) applications domains.

I have more problems writing Fortran 77 standard Fortran which is
portable, because of memory allocation issues, and bloody minded i/o.
But mostly because there are so few standard conforming compilers on
the machines I have to run on, and they differ in ways that make the
kind of code I write hard to implement.

Your milage will vary.

All anecdotal, of course.

+-+-+-+     I don't know who I am, why should you?     +-+-+-+
   |        fouts@lemming.nas.nasa.gov                    |
   |        ...!ames!orville!fouts                        |
   |        Never attribute to malice what can be         |
+-+-+-+     explained by incompetence.                 +-+-+-+