Function Parameter Expansion

[COTTRELL, JAMES]

/*
> I just spent an hour trying to figure out why my working program
> suddenly stopped working.  Here's the culprit:
> 
> 	    expand(*ptr++,*ptr++,*ptr++,ptr++,ptr++,ptr++);

Welcome to the club! You are certainly not the first!!! Try

expand(ptr[0],ptr[1],ptr[2],ptr[3],ptr[3],ptr[3]); ptr += 3;

Or maybe you mean (the compiler thinks you do):

expand(ptr[3],ptr[2],ptr[1],ptr[0],ptr[0],ptr[0]); ptr += 3;
 
> After careful searching of K&R I found the reason;
> 
> 	 The order of evaluation of arguments is undefined by the
> 	 language; take note that the various compilers differ.
> 							[p. 186]
> 
> The compiler I am using evaluates right to left.  If I were to number
> the above arguments 1-6, when expand gets them they are 6-1.  I find
> this contrary to my intuition.   

Intuition is often wrong. For example, most high level languages
index from one, when zero is much easier to deal with. I won't
even mention the Little Endian/Big Endian schism! (Hey, anyone
out there remember the `Big Indian' Pinball Machine?).

> Can anyone out there give me a good
> reason as to why this is left up to compiler implementation?  And
> if so is it generally true that evaluation of parameters is r-l?

Parameters are usually pushed on the stack right-to-left, so that
the first argument (and all others) is at a constant offset from
the stack (or frame) pointer. Some machines/compilers build
*argument* blocks forward (malloc'ed from a heap I guess) and
therefore do it `backwards' (forwards that is).

Allowing the particular implementation to choose makes everything
go fastest for everyone. Except if you don't know.

BTW, expressions such as a[i] = i++; are undefined as well.
You might get lucky sometimes, but don't press your luck.
 
> 
> 			Sincerely,
> 				  Michael Berman
> 					(tanj at ucscc.BITNET)

	jim		cottrell at nbs
*/
------