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: More Re: Function Argument Evaluation argument Message-ID: <18272@crdgw1.crd.ge.com> Date: 5 Apr 91 14:03:46 GMT References: <17936@crdgw1.crd.ge.com> <15607@smoke.brl.mil> Sender: news@crdgw1.crd.ge.com Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe) Lines: 60 In article , pds@lemming.webo.dg.com (Paul D. Smith) writes: |>Reference 2: Ibid, Section 3.3.2.2, p. 42, lines 20-21: |> |> "The order of evaluation of the function designator, the arguments, |> ^^^^^^^^^^^^^^^^^^^ |> and subexpressions within the arguments is unspecified, ... " |> ^^^^^^^^^^^ |> |>So given the following statement: |> |> printf("%d %d\n", (1, v), (1, v++)); |> ^^^^^^ ^^^^^^^^ |> exp. 1 exp.2 |> |>The compiler is free to choose whether to evaluate exp.1 first, or |>whether to evaluate exp.2 first. Once it chooses it must indeed |>evaluate the "1" first, before the "v" or "v++". |> |>So it's still undefined whether this prints "1 1" or "2 1". And |>rightly so, IMHO! Paul- You are misusing the term "undefined". It has a very specific meaning in the Standard, and doesn't simply mean "it can print this or it can print that". You are correct that the program can print "1 1" or "2 1", but that was also exactly my point. The point of this recent discussion was to find a program whose behavior is not undefined (according to the proper definition) yet still produces indeterminate (for lack of a better word) output. Notice that nowhere in that example is a violation of any "shall" rule outside of a constraint. Regardless of whether exp1 or exp2 is evaluated first, there is a sequence point immediately before each reference to "v". Note that if the behavior of this program were undefined, it would be allowed to core dump, or even print "Happy Birthday", or the compiler need not have even generated code in the first place! But here the output *must* be *either* "1 1" or "2 1". This is all subject to the comment Doug made about the possibility of the "unspecified order of subexpressions" overriding the "specified order and sequence point locations" of the comma operator. A formal interpretation would be needed on this, it seems, but I would suspect that the Committee would rule that the semantics of the comma operator hold, even when used as an argument to a function. But that's just my guess. If the semantics of the comma operator are maintained, then the evaluations of "v" and "v++" are always separated by a sequence point, regarless of the order of evaluation of exp1 and exp2. |> ------------------------------------------------------------------ |>| Paul D. Smith | pds@lemming.webo.dg.com | |>| Data General Corp. | | |>| Network Services Development Division | "Pretty Damn S..." | |>| Open Network Systems Development | | |> ------------------------------------------------------------------ ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com