Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!grebyn!ckp
From: ckp@grebyn.com (Checkpoint Technologies)
Newsgroups: comp.lang.c
Subject: Re: C problem, order of evaluation
Keywords: C, evaluationordrer, problem
Message-ID: <19595@grebyn.com>
Date: 11 Apr 90 14:55:22 GMT
References: <1990Apr8.185047.7385@diku.dk> <19539@grebyn.com> <16415@haddock.ima.isc.com> <1990Apr10.195822.14808@diku.dk>
Reply-To: ckp@grebyn.UUCP (Checkpoint Technologies)
Distribution: comp
Organization: Grebyn Timesharing, Vienna, VA, USA
Lines: 23

In article <1990Apr10.195822.14808@diku.dk> null@rimfaxe.diku.dk (Niels Ull Jacobsen) writes:
>
>      (stack[++sp] = g((stack[++sp] = make_cons(x,y), stack[sp -= 0]),
>                       (stack[++sp] = make_cons(x,z), stack[sp -= 0])),
>       stack[sp -= 2])
>
>The stack is actually only used to keep track of the cons-cells for
>the garbage collection.

Hmm... Sticky.  Something else to note is that a function call declares
a sequence point, therefore side effects are completed.  I see you're
calling g() above, so any (single) sp++ in the function arguments is
guaranteed to be done before the function call .. but there's no
relation between that and the calculation of the lvalue of the result
from the function call, so this may not help.

Hopefully your compiler will see that "sp -= 0" is a non-operation and
not generate any subtraction.  Philosophical question: is this still a
side effect?  Since this was generated from a preprocessor I assume that
0 may be a non-zero value in some cases, in which case...

Unfortunately I don't think I see an answer without temporary variables
and separate statements.