Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: C problem, order of evaluation
Keywords: C, evaluationordrer, problem
Message-ID: <16415@haddock.ima.isc.com>
Date: 9 Apr 90 20:54:14 GMT
References: <1990Apr8.185047.7385@diku.dk> <19539@grebyn.com>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Distribution: comp
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 19

In article <19539@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes:
>In article <1990Apr8.185047.7385@diku.dk> null@diku.dk (Niels Ull Jacobsen) writes:
>>"( stack[++sp]= exp , stack[sp -= N])", where exp contains N "stack[++sp]"'s.
>
>As long as that comma is really the comma *operator* and not the
>function argument separator, then the order of evaluation of your
>subexpressions *is* guaranteed....

I think the problem was with the multiple references to `sp' on the left side
of the comma.  Niels: am I correct in assuming that
	(stack[++sp] = stack[++sp] + stack[++sp], stack[sp -= 2])
is an example of the generated code?

My recommendation is to force your translator to generate code like
	(++sp, stack[sp] = stack[sp+1] + stack[sp+2])
instead.  That's the only way to be sure that the compiler knows what you're
talking about.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint