fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts) (09/23/88)
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. +-+-+-+
jlg@lanl.gov (Jim Giles) (09/24/88)
From article <1040@amelia.nas.nasa.gov>, by fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts): > [... example of non-porting C ...] > This is an argument by anecdote. [...] Yes, it's argument by anecdote. That is, it's exactly the sort of argument that's always used by C enthusiasts against Fortran. If it's invalid for me to use such arguments, then it's also invalid for C supporters. > 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.) This argument is invalid because the above is non-standard (not only that, the use of I in the do loop is illegal since I is declared to be an array). Any non-standard Fortran shouldn't be expected to port without _some_ degree of rewriting. The point about C is that THERE IS NO STANDARD. So, any example of non-portable C code I show you will demonstrate _my_ point in a perfectly valid manner. When a C standard becomes available, _then_ you can point to some mistake in my C examples - not until. One problem still remains with C, however. The proposed standard still contains some deliberately ambiguous forms. So, even after the standard exists, there will be non-portable standard conforming code. The Fortran committee seeks to avoid ambiguity - as a result, standard conforming Fortran code usually _does_ port. If it doesn't, it's _usually_ a compiler or library bug. Only very rarely does an ambiguous Fortran construct turn up - and when it does, there is usually a tacit agreement among users and implementors - an ambiguous feature is, for all practical purposes, a non-standard one. When THERE IS a C standard, C will be more portable. When the C standard starts to outlaw ambiguous features, C will be even as portable as Fortran (maybe). In the meantime, the Fortran standards committee is busy adding (I hope) most of the features that C users complain are missing. Fortran 77 will remain more portable that C throughout this change. Fortran 8x will also be portable, but only to those places which support the new standard. This latter problem faces C users as well - the new C standard will not be universally available right from the start. J. Giles Los Alamos
fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts) (09/24/88)
> >Yes, it's argument by anecdote. That is, it's exactly the sort of >argument that's always used by C enthusiasts against Fortran. If >it's invalid for me to use such arguments, then it's also invalid >for C supporters. > You are correct. You can, by going through archives, find me writing notes to C programmers telling them cut it out. . . >> 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.) > >This argument is invalid because the above is non-standard (not only >that, the use of I in the do loop is illegal since I is declared to >be an array). Any non-standard Fortran shouldn't be expected to port >without _some_ degree of rewriting. The point about C is that THERE >IS NO STANDARD. So, any example of non-portable C code I show you >will demonstrate _my_ point in a perfectly valid manner. When a >C standard becomes available, _then_ you can point to some mistake >in my C examples - not until. *PAY ATTENTION* THIS IS A FLAME In another note, Giles is bemoaning that people are jumping down his throat. Open wide and I'll explain why. What you have done with the above is taken a quote out of context and changed its meaning. I wasn't discussing *standard conforming* code, I was discussing *portable* code. Radically different issues. (See my subject line.) You claimed by anecedote that C was not portable because of you had some examples of C code which hadn't been well written for portability. I gave the above as an example of a Fortran code which wasn't written for portability and was difficult to port. I also went on to say that I don't take this example as proof that Fortran is a hard language to write portable code in. This thought seems to have disapeared from your counter. [By the way, the code (other than the I which should have been a J) is standard conforming code. The Fortran standard allows me to make all the out of bounds references I want. It just doesn't require all compilers to do the same thing.] If you want to alter the point under discussion, fine, but don't do it by taking something I said out of context. Then I won't jump on you. *END FLAME* +-+-+-+ 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. +-+-+-+
jlg@lanl.gov (Jim Giles) (09/24/88)
From article <1052@amelia.nas.nasa.gov>, by fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts): > *PAY ATTENTION* THIS IS A FLAME > [...] > What you have done with the above is taken a quote out of context and > changed its meaning. I wasn't discussing *standard conforming* > code, I was discussing *portable* code. Radically different > issues. (See my subject line.) You claimed by anecedote that C was not > portable because of you had some examples of C code which hadn't been > well written for portability. I gave the above as an example of a > Fortran code which wasn't written for portability and was difficult to > port. [...] *PAY ATTENTION* THIS IA ALSO A FLAME!! I began this discussion with a statement that _Fortran_ was more portable than C. You _did_not_ give an example of Fortran code of any kind. You gave an example of Fortran-like code which wouldn't port!! So, I WAS DISCUSSING STANDARD CONFRMING CODE!!!!! When I say Fortran, I mean standard conforming code!! I often mention extensions, but I always clearly say that they are extensions. Since C has no standard (and the proposed one is deliberately ambiguous) I still claim that _Fortran_ is more portable than C. > [...] The Fortran standard allows me to > make all the out of bounds references I want. [...] No, it doesn't!!! Many Fortran compilers allow you to. Fortran doesn't! END FLAME? (probably not - but one has hopes.) J. Giles Los Alamos
peter@ficc.uu.net (Peter da Silva) (09/26/88)
In article <4089@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: > One problem still remains with C, however. The proposed standard still > contains some deliberately ambiguous forms. So, even after the standard > exists, there will be non-portable standard conforming code. This is a straw man. Of course C can be used to write standard-conforming programs that aren't portable. It is intended to. C is designed for doing things that cannot be done in a portable way: writing operating systems and device drivers for example. It is designed to let you get down and dirty with the hardware, so you can avoid mucking around with assembly. It is never going to be pure enough to satisfy you. The ability to write complete device drivers, including interrupt handlers, in C is to important to give up in the name of religion. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net