Messages in this thread | | | Date | Tue, 17 Oct 2000 00:32:21 +0300 | From | Matti Aarnio <> | Subject | Re: Patch to remove undefined C code |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |