Theory of Pure C, chapter 937

[utzoo!decvax!duke!harpo!utah-cs!sask!hssg40!peachey]

	Regarding the side-effects of 'x++' used as function argument:

	The best solution is probably to make the order of the x++
	and the call to bar() "undefined".  I guess that this is
	what the existing language documents do.  To say it is
	"undefined" is to imply that only a fool would write a
	program which depended on the order, assuming he cared
	about portability.

	Of course, in practice everybody will go and write such
	programs anyway, because they are "only planning to use
	the programs once".  So best of all is a language/compiler
	which actively PREVENTS you from writing programs which
	depend on such things.

	Philosophically, I guess I believe this, but as a professional
	C programmer, I can't really see how to enforce these
	rules in my favorite language without reducing the joyous
	freedom of C programming.  Therefore, I suggest that the
	best compromise is to choose one or the other evaluation
	order and specify it as the only correct behavior.  This
	will certainly make some compiler writer's job harder,
	but is probably worth it.

	My final point is that maybe it makes sense for the full
	effects of 'x++' to take place before the call to bar(),
	since 'x++' as an expression must be evaluated before
	the call is made.  A very simple compiler could concern
	itself with generating code for 'x++', as a subtask
	of compiling 'bar(x++)'.  None of the effects of the
	inner subexpression would result in code generated
	after the code for the function call.  Under these rules
	'bar()' would see the new value of global variable 'x'.

				Darwyn Peachey
				Hospital Systems Study Group

				harpo!utah-cs!sask!hssg40!peachey