Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ucla-cs!maui.cs.ucla.edu!jon
From: jon@maui.cs.ucla.edu (Jonathan Gingerich)
Newsgroups: comp.std.c
Subject: Re: More Re: Function Argument Evaluation argument
Message-ID: <1991Apr5.182945.15789@cs.ucla.edu>
Date: 5 Apr 91 18:29:45 GMT
References: <15607@smoke.brl.mil> <PDS.91Apr2203927@lemming.webo.dg.com> <18272@crdgw1.crd.ge.com>
Sender: usenet@cs.ucla.edu (Mr. News Himself)
Organization: UCLA Computer Science Department
Lines: 28
Nntp-Posting-Host: maui.cs.ucla.edu

In article <18272@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
>|>
>|>    printf("%d %d\n", (1, v), (1, v++));
>|>                      ^^^^^^  ^^^^^^^^
>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. 

Where are the sequence points on the comma operator?  I would guess there
is only one between the first and second expression in which case the
evaluation order 1 - 1 - (sequence point) - (sequence point) - v - v++
would make the result undefined.  The output of:

	printf("%d %d\n", f(...v...), f(...v++...)) 

is unspecified and not undefined because the sequence point before f(), but
since the subexpressions ...v... and ...v++... cannot be interleaved (unless
this is a case of the ambiguity Doug was talking about), it is not as
interesting.

Jon.