Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!hc!ames!sgi!wdl1!rion
From: rion@wdl1.UUCP (Rion Cassidy)
Newsgroups: comp.lang.c
Subject: another auto-increment problem
Message-ID: <3680001@wdl1.UUCP>
Date: Fri, 25-Sep-87 16:36:19 EDT
Article-I.D.: wdl1.3680001
Posted: Fri Sep 25 16:36:19 1987
Date-Received: Sun, 27-Sep-87 02:46:42 EDT
Lines: 48

Preface:
	This is my first time posting to comp.lang.c; please excuse me
	if this problem has been brought up and beaten to death before.



While attempting to use the auto-increment operation to improve efficiency
of array accesses, I discovered what is an implementation detail (and
therefore not specified in the language) that most people would not
expect.

Consider the following definitions:

	float junk[3], *junk_ptr;
		/* junk contains x,y,z coords */

and use thereof:

	junk_ptr = (float *) junk;
	xfpt(*junk_ptr++, *junk_ptr++, *junk_ptr);
		/* transform x,y,z coords to a coord new system */

At first glance, most people would assume that the following function
call is equivalent, but slightly slower:

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

This assumption is based on the premise that the arguments to xfpt()
are evaluated left to right; if their are *NOT* we can be sure that we
will get the wrong values passed to xfpt.

Perhaps it is because we are so used to expressions getting evaluated
left to right that we just assume function arguments will as well (and
why on Earth *WOULDN'T* they implement it that way?).  As it turns
out, everyone I explained the problem to made the same assumption I
had (args evaluated left to right), but all our UNIX systems have
implementations that evaluate function arguments right to left!!

I presume this has something to do with the order in which the
arguments have to be pushed and popped on the stack, but I can't see
why it would really make a difference.

Are their any C-compiler implementors out there that would care to
comment? 

Rion Cassidy
<rion@wdl1>
{ucbvax|sgi|sun}!wdl1!rion