Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!daemon
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: stack quirk?
Message-ID: <1990Aug2.045452.20832@athena.mit.edu>
Date: 2 Aug 90 04:54:52 GMT
References: <4047@pikes.Colorado.EDU> <31530012@hpcvia.CV.HP.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: scs@adam.mit.edu (Steve Summit)
Organization: Thermal Technologies, Inc.
Lines: 38

In article <31530012@hpcvia.CV.HP.COM> brianh@hpcvia.CV.HP.COM (brian_helterline) writes:
(in response to a code fragment like printf("%d %d\n", i++, i++);)

>	The arguments to
>	printf() [or any function] are pushed on to the stack
>	right to left so they are in the correct order for
>	printf() to pop them off when needed.

Though correct for many machines, this is not true in general,
for the C language neither mandates stack direction nor the
existence of a stack.  When you hear that evaluation order, and
hence the behavior of an expression containing multiple side
effects, is "undefined," it means that you cannot predict and
should not know how various machines will do it, and that
different machines may do it differently.  To quote our good
friends K&R, "Naturally, it is necessary to know what things to
avoid, but if you don't know _how_ they are done on various
machines, that innocence may help to protect you."

>	I am not certain as to what ANSI specifies about whether this
>	behavior is correct or not.

ANSI C reaffirms that evaluation order in such cases is
undefined, and furthermore (so I have been told) gives compilers
license to reject programs depending on undefined evaluation
order at compile time, without even flipping a coin and picking
an order.

>	It is usually a bad idea to use ++ operators
>	on the same variable more than once in _ANY_ expression.

Correct, except that the operative adverb is "always."

See the frequently asked questions list for a bit more on this
topic.

                                            Steve Summit
                                            scs@adam.mit.edu