Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ames!decwrl!sdd.hp.com!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Function calls in the middle of subroutine CALLs? -- Is it standard fortran 77 ????
Message-ID: <59110@lanl.gov>
Date: 3 Aug 90 22:34:46 GMT
References: <2022@key.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 24

From article <2022@key.COM>, by sjc@key.COM (Steve Correll):
> In article <58237@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
>> > 	X .GT. Y .OR. L(Z)
> [...]
> 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've recieved this response from several other people as well.  I was
going to handle the problem by email, but it keeps coming up.

C is predictable only if you know in advance whether X was greater than
Y.  If I knew that, I wouldn't have tested it.  This is what I meant
when I said that neither language is defined in such a way as to be
able to tell a priori (from the first) whether the function would be
evaluated or not.  This means that I can't optimize by doing the function
and the compare simultaneously (actually, in Fortran I _can_ optimize like
that, but the user can't portably rely on it).  It also means that I can't
apply the mathematical properties of the 'or' operator to correctness
proofs of the program.

J. Giles