More Re: Function Argument Evaluation argument

Christopher R Volpe volpe at camelback.crd.ge.com
Sat Apr 6 00:03:46 AEST 1991


In article <PDS.91Apr2203927 at lemming.webo.dg.com>,
pds at 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 at 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 at crd.ge.com



More information about the Comp.std.c mailing list