Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!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: <18320@crdgw1.crd.ge.com>
Date: 8 Apr 91 12:34:30 GMT
References: <18272@crdgw1.crd.ge.com> <1991Apr5.182945.15789@cs.ucla.edu> <18286@crdgw1.crd.ge.com> <3693@inews.intel.com>
Sender: news@crdgw1.crd.ge.com
Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe)
Lines: 38

In article <3693@inews.intel.com>, bhoughto@nevin.intel.com (Blair P.
Houghton) writes:
|>
|>The line read (essentially):
|>
|>	f ( ( 1 , v) , ( 1 , v++ ) ) ;
|>
|>I expect you're not confusing the two comma operators with the
|>comma separator in this function call.  

Nope, I'm not, but thanks for pointing it out. 

|>The sequence point
|>after the left operand of each comma-operator serves only
|>to define the end of operations on the left operand and the
|>beginning of operations on the right operand; it does not
|>affect the order in which the two arguments to the function
|>are evaluated.  However, what you may be saying is that the
|>sequence of abstract events
|>
|>        1 - 1 - ( seq. pt. ) - ( seq. pt. ) - v - v++
|>
|>is incorrect, and would be
|>
|>        1 - ( seq. pt. ) - 1 - ( seq. pt. ) - v - v++

I'd say it would at least have to be that. I would have also expected that
the right operand of the first comma-operator evaluated had to be evaluated
before the left operand of the second comman-operator evaluated, until
someone mentioned that bit about only specifying a partial ordering.
So perhaps the above function call is not an example of one whose behavior
is not undefined.

                                                   
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com