Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: ambiguous ?
Message-ID: <14111@lanl.gov>
Date: 23 Oct 89 21:42:20 GMT
References: <6637@ficc.uu.net>
Organization: Los Alamos National Laboratory
Lines: 50

From article <6637@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> [...]
> This has nothing to do with function calls that have side effects. We're
> talking about evaluation order of arguments... expressions that have side
> effects being used in arguments to function calls.

I've already discussed this case in THREE previous submissions!  If the
_expressions_ used as arguments have dependent side effects, if a compiler
is capable of optimizing the order of argument evaluation in any useful
way (that is, both correct and efficient), than that compiler is _also_
capable of detecting the dependencies and enforcing some fixed evaluation
order on them.  The C standard would loose _NO_ useful optimization
potential by specifying the _effective_ order in which arguments were
to be evaluated.

> You may be confused because in Fortran the only way an expression can have
> side effects is if it involves a function call.

I am obviously _not_ confused in that manner.  Everyone seems to assume
any opponent of C must be some reactionary neanderthal committed to
Fortran.  Anyone who reads comp.lang.fortran can vouch for the fact
that I find a good number of things wrong with Fortran!  In fact, what
I really want is for programming language technology to _advance_!
Neither C nor Fortran are advances.  There are things to be learned
from both of them though - mistakes as well as good ideas.  I can't
understand the "reactionary neanderthal" attitude of many C programmers
who seem to feel that there's no way to improve their language and
no point in discussing its faults.

> [...]
> 		DATA I /0/
> 		J = I * GETCH(5)
> 		J = 0 * GETCH(6)
> Is this legal?
> Is it guaranteed that GETCH(5) will be evaluated?
> Is it guaranteed that GETCH(6) will be evaluated?
> C makes these guarantees.


However, C does not guarantee that the following two functions will
be evaluated:

      if (getch(5) && getch(6)) {...}

Once again, your assumption that I believe Fortran to be perfect is
not correct.  As I've already pointed out, it should be possible to
explicitly specify whether a function has side effects and the
language definition should be scrupulously specific about the evaluation
order (as well as _whether_ they are evaluated) in the presence of
such side effects.