Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!apple!sun-barr!newstop!sun!amdahl!key!sjc
From: sjc@key.COM (Steve Correll)
Newsgroups: comp.lang.fortran
Subject: Re: Function calls in the middle of subroutine CALLs? -- Is it standard fortran 77 ????
Message-ID: <2022@key.COM>
Date: 2 Aug 90 22:16:03 GMT
References: <2009@key.COM> <58237@lanl.gov>
Organization: Key Computer Labs, Fremont, CA
Lines: 25

In article <58237@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <2009@key.COM>, by sjc@key.COM (Steve Correll):
> > [...]
> > 	X .GT. Y .OR. L(Z)
> > 
> > where L is a logical function which defines its dummy argument. The standard
> > says that if X is greater than Y, then Z becomes undefined. Not very user-
> > friendly, but Fortran programmers have traditionally been tough as nails.
> 
> Since this started as a comparison to C, let's remember that C is just
> as bad here.  You can't predict a-priori whether the function L() will
> be executed in either language.

C is predictable. The Fortran standard says that the processor _need_ _not_
execute the function L if X exceeds Y, and that therefore the program must
assume Z is undefined. The C standard for "(x > y) || l(&z)" says that the
processor _must_ _not_ execute l if x exceeds y, so the program may therefore
assume z is unchanged.

I make no judgement about which definition is better. I didn't mean to
disparage Fortran in the first place, just to make clear that the Fortran 77
standard explicitly relieves the translator of the obligation of worrying about
side effects in this case, putting the onus on the programmer to avoid them.
-- 
...{sun,pyramid}!pacbell!key!sjc 				Steve Correll