Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!camelback!volpe From: volpe@camelback.crd.ge.com (Christopher R Volpe) Newsgroups: comp.std.c Subject: Re: Function Argument Evaluation Message-ID: <17750@crdgw1.crd.ge.com> Date: 20 Mar 91 21:50:02 GMT References: <7621@polstra.UUCP> Sender: news@crdgw1.crd.ge.com Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe) Lines: 43 In article <7621@polstra.UUCP>, jdp@polstra.UUCP (John Polstra) writes: |>Consider the following program: |> #include |> 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@crd.ge.com