Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!amdcad!tim
From: tim@amdcad.AMD.COM (Tim Olson)
Newsgroups: comp.lang.c
Subject: Re: another auto-increment problem
Message-ID: <18426@amdcad.AMD.COM>
Date: Sat, 26-Sep-87 15:52:55 EDT
Article-I.D.: amdcad.18426
Posted: Sat Sep 26 15:52:55 1987
Date-Received: Sun, 27-Sep-87 11:12:35 EDT
References: <3680001@wdl1.UUCP>
Reply-To: tim@amdcad.UUCP (Tim Olson)
Organization: Advanced Micro Devices
Lines: 34

In article <3680001@wdl1.UUCP> rion@wdl1.UUCP (Rion Cassidy) writes:
+-----
| 	junk_ptr = (float *) junk;
| 	xfpt(*junk_ptr++, *junk_ptr++, *junk_ptr);
| 		/* transform x,y,z coords to a coord new system */
|
| Are their any C-compiler implementors out there that would care to
| comment? 
+-----
There are two problems with this statement.  First of all, as you found
out, the order of evaluation of procedure parameters is not stated; some
compilers will evaluate right-to-left, while others will evaluate
left-to-right (as you presumed, this usually has to do with how stack
frames are built to pass parameters).  However, there is another
problem.

The ANSI standard states that "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 means that the increment of junk_ptr does not have to take effect
until just before the call, so (legally) the expressions could evaluate to:

	xfpt(junk_ptr[0], junk_ptr[0], junk_ptr[0]);

or other non-obvious combinations.  The only safe way to perform this
function call is

	xfpt(junk_ptr[0], junk_ptr[1], junk_ptr[2]);
	

	-- Tim Olson
	Advanced Micro Devices
	(tim@amdcad.amd.com)