josh@hi.uucp (Josh Siegel ) (04/18/87)
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:
.
.
.
struct foobar *getit();
doit(getit(5)->foo1, getit(7)->foo5)
.
.
.
When getit() returns a pointer to a internal static buffer.
Should it be allowed to do this? yes yes.. I know I should
just use a temp var but thats not the point! Whine!!!
Sigh...
--
Josh Siegel (siegel@hc.dspo.gov)
(505) 277-2497 (Home)
I'm a mathematician, not a programmer!edw@ius2.cs.cmu.edu.UUCP (04/18/87)
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 They say there are strangers, who threaten us In our immigrants and infidels They say there is strangeness, too dangerous In our theatres and bookstore shelves Those who know what's best for us- Must rise and save us from ourselves Quick to judge ... Quick to anger ... Slow to understand... Ignorance and prejudice and fear [all] Walk hand in hand. - RUSH
josh@hi.uucp (Josh Siegel ) (04/19/87)
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!