Function Argument Evaluation

[Christopher R Volpe]

In article <7621 at polstra.UUCP>, jdp at polstra.UUCP (John Polstra) writes:
|>Consider the following program:
|>    #include <stdio.h>
|>    int x = 100, y = 200, *p;
|>    main() {
|>	printf("%d %d\n", *(p = &x), *(p = &y));
|>    }
|>Could a conforming compiler translate this in such a way that the output
|>of the program is "200 200"?

No, it can't.

|>I believe it could, based on this quote from section 3.3.2.2 of the
|>October 31, 1988 draft:
|>
|>    The order of evaluation of the function designator, the arguments,
|>    and subexpressions within the arguments is unspecified, but there is
|>    a sequence point before the actual call.
|>
|>If I understand correctly, it would be valid to evaluate in this order:
|>
|>    "%d %d\n"	/* First argument */
|>    (p = &x)	/* Subexpression within second argument */
|>    (p = &y)	/* Subexpression within third argument */
|>    *p		/* Second argument */
|>    *p		/* Third argument */

      ^^^ These are not in fact the second and third arguments of the
function. Stick an asterisk in front of each of the subexpressions you
listed above and then you have the second and third arguments. It is not
the value of p at the time of the call that is being dereferenced here.
It is the result of the assignment expression that is being dereferenced, 
and that has nothing to do with any side effects that take place anywhere
in this example. Nowhere in the example are you "reading" p's value.
The value of the expression "(p = &x)" is "&x". Therefore,
"*(p = &x)" is "*(&x)" which is x.

So, the output has to be "100 200".
                                     
==================
Chris Volpe
G.E. Corporate R&D
volpecr at crd.ge.com