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. +-+-+-+