Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!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: <1991Apr8.191009.24897@cs.ucla.edu>
Date: 8 Apr 91 19:10:09 GMT
References: <RJOHNSON.91Apr1142143@olorin.shell.com> <18140@crdgw1.crd.ge.com> <1991Apr6.022220.6449@twinsun.com>
Sender: usenet@cs.ucla.edu (Mr. News Himself)
Organization: UCLA Computer Science Department
Lines: 30
Nntp-Posting-Host: maui.cs.ucla.edu

In article <1991Apr6.022220.6449@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>
>While the ANSI standard does not clearly address this point, Jim Brodie
>has reported [Journal of C Language Translation 2, 3 (Dec. 1990), 207-215]
>that the general opinion of X3J11 seems to be that the sequence point
>in an expression X=F(Y) prior to the call to F causes only a partial
>ordering on the subexpressions F and Y; it does not control the
>ordering of other subexpressions like X.  From this, I would expect

Earlier I claimed:

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

was unspecified not undefined based on a misapprehension of where the sequence
point in a function calls is.  Looking at K&RII it appears that the s.p. is 
between the evaluation of the arguments (and function name) and the application
of the functions.  I.e.

	x = double_it(x++);

would always leave x even.  In my previous example however, I believe that v
and v++ could be evaluated before either s.p. thus it is undefined.

So what about:

	 (*fp)(fp = &g)

???

Jon.