Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!convex!grogers
From: grogers@convex.com (Geoffrey Rogers)
Newsgroups: comp.std.c
Subject: Re: More Re: Function Argument Evaluation argument
Message-ID: <1991Apr02.140313.17225@convex.com>
Date: 2 Apr 91 14:03:13 GMT
References: <15607@smoke.brl.mil> <RJOHNSON.91Apr1142143@olorin.shell.com> <18140@crdgw1.crd.ge.com>
Sender: news@convex.com (news access account)
Organization: Convex Computer Corporation, Richardson, Tx.
Lines: 34
Nntp-Posting-Host: mozart.convex.com

In article <18140@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
>In article <RJOHNSON.91Apr1142143@olorin.shell.com>, rjohnson@shell.com
>(Roy Johnson) writes:
+|>I understand that the comma operator is a sequence point.
+|>If we use the comma operator as a sequence point between evaluations:
+|>
+|>   int v=1;
+|>   printf("%d %d\n", (1, v), (1,v++));
+|>
+|>This can print
+|>	1 1
+|>or
+|>	2 1
+|>
+|>Do I win?  8^)
+
+Hey, that looks pretty good. No matter what the order of evaluation of
+the function arguments is, there's always a sequence point separating the
+references to v. So the behavior is not undefined, yet order of evaluation
+definitely has a drastic effect on the output. 
+
+Anybody see a problem with that?

No. 

In this case the compiler must evaluate 1 before it evaluate v or v++
in the subexpressions '(1,v)' and '(1,v++)'. But the order of
evaluation of these two subexpressions are still undefined.

+------------------------------------+---------------------------------+
| Geoffrey C. Rogers   		     | "Whose brain did you get?"      |
| grogers@convex.com                 | "Abbie Normal!"                 |
| {sun,uunet,uiucdcs}!convex!grogers |                                 |
+------------------------------------+---------------------------------+