Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclcdb!cdb From: cdb@hpclcdb.HP.COM (Carl Burch) Newsgroups: comp.lang.fortran Subject: Re: fortran problem Message-ID: <6690017@hpclcdb.HP.COM> Date: 13 Jun 88 19:59:13 GMT References: <8806111222.AA06982@jade.berkeley.edu> Organization: HP ITG/ISO Computer Language Lab Lines: 32 Unfortunately, any such program is not standard-conforming, and the standard therefore says exactly nothing about its required behavior. The relevant passage of the F77 standard is paragraph 15.9.2 on page 15-16 : "Actual arguments may be constants ... if and only if the associated dummy argument is a variable that is not defined during execution of the referenced external procedure." The Fortran 8x draft standard has similar words, and is quite likely to retain them in light of the F8x Prime Directive - to be 100% F77 compatible. There are some tools that try to find such problems - see the previous notestrings on Fortran lint. I don't know if they mentioned MAT from SAIC, or flint from Programming Research Ltd in England. I haven't used either one, but they're both made by nice guys that know more about the problem than I do. As for your general implication on the quality of compilers that cause this sort of problem, I wish you hadn't mentioned the specific companies you compared - I could be somewhat more candid in the abstract. As it is, I will just report that the problem you cite was used as a horror story in the compiler-writing class I took at Purdue in 1981 - with the professor's opinion that this story is so famous that nobody would ever do it "wrong" again. Silly him. Actually, after a similar conversation with a couple HP customers at a users group conference I found to my dismay that HP still has one compiler (F7x on the HP1000) that also allows constants to change value this way. So (as the saying goes) "Let's be CAREFUL out there!" - Carl Burch cdb%hpda@hplabs.HP.COM HP Fortran Team