🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #2678

Re: More Re: Function Argument Evaluation argument

#2678
From: Christopher R Volpe
Date: Fri, 05 Apr 1991 14:03
60 lines
3482 bytes
In article <PDS.91Apr2203927@lemming.webo.dg.com>,
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
Technical Details
Message-ID: <18272@crdgw1.crd.ge.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!camelback!volpe
References: <17936@crdgw1.crd.ge.com> <15607@smoke.brl.mil> <PDS.91Apr2203927@lemming.webo.dg.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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> <PDS.91Apr2203927@lemming.webo.dg.com>
Sender: news@crdgw1.crd.ge.com
Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe)
Lines: 60