Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!hc!hi!josh From: josh@hi.uucp (Josh Siegel ) Newsgroups: comp.lang.c Subject: Re: Stupid evaluation ordering. Is this legal? Message-ID: <4627@hi.uucp> Date: Sun, 19-Apr-87 02:34:12 EST Article-I.D.: hi.4627 Posted: Sun Apr 19 02:34:12 1987 Date-Received: Sun, 19-Apr-87 18:01:22 EST References: <4395@hi.uucp> <1104@ius2.cs.cmu.edu> Reply-To: josh@hi.UUCP (Josh Siegel) Organization: U. of New Mexico, Albuquerque Lines: 71 Keywords: K&R, Bible, PCs, UNIX In article <1104@ius2.cs.cmu.edu> edw@ius2.cs.cmu.edu (Eddie Wyatt) writes: >In article <4395@hi.uucp>, josh@hi.uucp (Josh Siegel ) writes: >> I just lost a argument and am running to the net for comfort... >> >> According to K&R(Bible) page 185, a C compiler is allowed to do the >> following. >> >> Given: >> >> a(b()+c(),d()+e()) >> >> It is allowed to run functions b() and d(), then run >> c() and e(), THEN add them (This has shades of >> compilers that optimise on parallel machines). >> This causes problems with stuff like: > > > Never assume anything about the order of evaluation of parameters to >a function. One thing, you are not guarenteed that b()+c() will be >evaluated before d()+e(). I know, I had code break because of this >very same thing. I'm not sure,but you may not even be guarenteed that >b() will be evaluated before c(). Is it consider a legal optimization - >to reorder the sequence of function calls within an expression? > >-- > Eddie Wyatt FLAME ON!! READ THE QUESTION!!! FLAME OFF! I said "c() and e()". Not, "b()+c()". I am talking about the compiler doing.. a(b()+c(),d()+e()) Compiled b() -> temp1 d() -> temp2 c() -> temp3 e() -> temp4 temp1+temp3->STACK temp2+temp4->STACK As apposed to: e()+d() -> stack c()+b() -> stack Oh well... it turns out that we found proof in K&R that says that they can't do a(b(4)->left,b(5)->right) in the following order: b(4) -> temp1 b(5) -> temp2 follow temp1 follow temp2 Once it starts a expression it will complete it (in what ever order it wishes) as restricted by K&R. --Josh Siegel -- Josh Siegel (siegel@hc.dspo.gov) (505) 277-2497 (Home) I'm a mathematician, not a programmer!