Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: printf() problem
Keywords: C printf
Message-ID: <1512@auspex.auspex.com>
Date: 28 Apr 89 10:07:22 GMT
References: <11657@hodge.UUCP> <89Apr26.092233edt.18850@me.utoronto.ca>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>C puts its function parameters on the stack in "reverse" order,

No, the C implementation being described happens to do so.  C has no
notion of "the stack", and it certainly has no notion that the function
parameters are "put onto the stack" in some particular order, or even
that those arguments are *evaluated* in some particular order!   To
quote, yet again, from the pANS:

	3.3.2.2 Function calls

		...

	Semantics

		...

	   The order of evaluation of the function designator, the
	arguments, and subexpressions within the arguments is
	unspecified, but there is a sequence point before the actual
	call.

>>    This happens in both Turbo C 2.0 and MS C 5.1.
>
>It would happen in any C.

Guess again.  A C implementation could, if it wished, evaluate the four
function calls in the arguments in the "printf" call from left-to-right,
right-to-left, or in any other order that it chose.  Do NOT write code
that depends on them being evaluated in ANY particular order, unless you
1) absolutely positively MUST have code of that sort and 2) absolutely
postively KNOW that your code will only be used on implementations where
the arguments are evaluated in the particular order in which you expect
them to be evaluated.