On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote:
> > > $ The order of evaluation of the function designator, the
> > > $ arguments, and subexpressions within the arguments is
> > > $ unspecified, ...
> >
> > I sit surprised and corrected. With every version of every C compiler on
> > every OS I have ever used (over 100 combinations from AmigaDOS 1.1 using
> > Manx C to E10000 using Kai C++) the behavior has been the same for parameter
> > lists as for the comma operator in this respect.
>
> Yes. In practice the usual question is whether the compiler will
> evaluate the operands from left to right or from right to left,
> but the compiler is within its rights to evaluate the operands in
> any order it wants.
That depends mainly on question: Does your stack grow up or down ?
Machines where stack grows up are a bit rare, but they do exist.
The CISC archetype, IBM S/360/370/390 has simple instruction to
add a small positive offset value into pointer register, but not
to substract it (nor have negative offsets). Thus most stackfull
languages there have the stack growing up. Doing downwards-growing
stack setup requires 1 extra register use, and one extra instruction
per frame entry, plus considerably more for parameter push.
(But it was a great beast to run Fortran-IV which didn't need stack,
just subfunction invocation record -- at a static location unique
for each subfunction --> no recursion supported.)
> > Does this imply that even the evaluation of a function pointer
> > is itself undefined in terms of ordering?
>
> Yes.
For things like lone pointer referral with pre/post inc/dec:
*p++
it is well defined, but for things like:
*p++ + *p
it is not. (Will the second *p be evaluated before or after *p++
post-increment ?)
/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
