ambiguous ?

[Jim Giles]

>From article <2320 at convex.UUCP>, by grogers at sushi.uucp (Geoffrey Rogers):
> In article <14104 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
>>From article <6613 at ficc.uu.net>, by peter at ficc.uu.net (Peter da Silva):
>>> [ in Fortran,
>>> 	CALL SUBR(FUNC, FUNC)
>> [... I said statement was illegal in Fortran is FUNC has side effects ...]
> It is! Where does it say that in the FORTRAN 77 standard? Here what the 
> Fortran 77 standard says:
" 6.6.2 Order of Evaluation of Functions. [...]                                 
" In a statement that contains more than one function reference, the value
" provided by each function reference must be independent of the order chosen
" by the processor for evaluation of the function reference.
> 
> From this I would say that the first calling sequence is legal no matter
> what the side effects are from the evaluation order of the functions. 

And you'd be wrong!  The quoted part of the standard clearly states that
if the value that FUNC returns is effected by the order of the two calls,
the statement is illegal.  Such a statement doesn't conform to a "must"
clause in the standard!

To make this more clear, suppose the first call to FUNC returns 0.5 and
the second returns 1.5.  Clearly CALL SUBR(0.5,1.5) is different than
CALL SUBR(1.5,0.5).  The Fortran standard prohibits the original form
of the call specifically to allow the optimization without ambiguity.

< [...]                                              If you are
< going to compare C to other languages such as FORTRAN, please know what
< in the standard before you say what is or isn't legal.

I would say the same to you.  Especially since I had already quoted
that part of the standard in a previous posting.

To get this back to a C related subject: please note (again) that I
do _not_ recommend the Fortran rules as better than C (not for this
issue anyway :-).  The above Fortran rule is too restrictive.  The
C rule is too permissive.  The middle ground would give the user
more control _and_ better insure the correctness of the code.