Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!ogicse!intelhf!ichips!iwarp.intel.com!inews!hopi!bhoughto
From: bhoughto@hopi.intel.com (Blair P. Houghton)
Newsgroups: comp.std.c
Subject: Re: Function Argument Evaluation
Message-ID: <3461@inews.intel.com>
Date: 26 Mar 91 00:35:51 GMT
References: <1991Mar23.014442.24307@cs.ucla.edu> <15565@smoke.brl.mil> <1991Mar25.174542.24419@cs.ucla.edu>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 65

In article <1991Mar25.174542.24419@cs.ucla.edu> jon@maui.cs.ucla.edu (Jonathan Gingerich) writes:
>I understand perfectly well that *(p=&x) can be evaluated "after" p has been
>assigned &y.  But does this affect the value of p=&x?  I.e. does "the value
>of the left operand after the assignment" mean "immediately after" or 
>"sometime after, before the next sequence point"?

The twilight zone:

	f( *(p = &x), *(p = &y) );

The necessary operations to produce a stack full of arguments:

(1)         p <-- &x              (3)       p <-- &y
(2)     stack <-- *p              (4)   stack <-- *p

The order in which we'd all like to see them performed
is, of course, 

(1)         p <-- &x
(2)     stack <-- *p
(3)         p <-- &y
(4)     stack <-- *p

but the standard says that the only thing that has to be true
is that 2 is later than 1 and 4 is later than 3; this is
evident from the parentheses.

thus the following cases are also possible:

(1)         p <-- &x                     (1)         p <-- &x
(3)         p <-- &y                     (3)         p <-- &y
(2)     stack <-- *p                     (4)     stack <-- *p
(4)     stack <-- *p                     (2)     stack <-- *p

(3)         p <-- &y                     (3)         p <-- &y
(1)         p <-- &x                     (1)         p <-- &x
(2)     stack <-- *p                     (4)     stack <-- *p
(4)     stack <-- *p                     (2)     stack <-- *p

(3)         p <-- &y
(4)     stack <-- *p
(1)         p <-- &x
(2)     stack <-- *p

You could also break it down to the level of

(1)     addr <-- x
(2)        p <-- addr
(3)    value <-- p
(4)    stack <-- value
(5)     addr <-- y
(6)        p <-- addr
(7)    value <-- p
(8)    stack <-- value

But I'm not going to...

Notice that this isn't merely an exercise in unspecificity;
it's also an example of the asynchrony of parallelism, and
could be a useful exercise in someone's parallel-processing
class.

                                --Blair
                                  "No copyright. Just send me
                                   a copy if you get it right.