Function Argument Evaluation
Blair P. Houghton
bhoughto at hopi.intel.com
Tue Mar 26 10:35:51 AEST 1991
In article <1991Mar25.174542.24419 at cs.ucla.edu> jon at 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.
More information about the Comp.std.c
mailing list