Path: utzoo!utgpu!cunews!cognos!jimp
From: jimp@cognos.UUCP (Jim Patterson)
Newsgroups: comp.std.c
Subject: Re: Function Argument Evaluation
Message-ID: <9439@cognos.UUCP>
Date: 26 Mar 91 16:04:21 GMT
References: <7621@polstra.UUCP> <17750@crdgw1.crd.ge.com> <1991Mar25.195234.7179@sq.sq.com>
Reply-To: jimp@cognos.UUCP (Jim Patterson)
Organization: Cognos Inc., Ottawa, Canada
Lines: 33

In article <1991Mar25.195234.7179@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
>Chris Volpe (volpecr@crd.ge.com):
>> in this example. Nowhere in the example are you "reading" p's value.
>> The value of the expression "(p = &x)" is "&x". Therefore,
>> "*(p = &x)" is "*(&x)" which is x.
>
>Chris is right about the error in John's analysis.  The value of an
>assignment expression is the value of its right-hand operand, converted
>to the top of its left-hand operand.

You should both read the standard again. Section 3.3.16 Assignment Operators
under "Semantics" says:

    An assignment operator stores a value in the object designated
    by the left operand. An assignment expression has the value of the
    LEFT operand after assignment, but is not an lvalue. [...] The side
    effect of updating the stored value of the left operand shall occur
    bgetween the previous and the next sequence point.

(emphasis mine, from ANSI X3.159-1989, approved version, page 54)

So, *(p=&x) is actually *(p) after assignment, not *(&x), and any of the
four results quoted previously is possible.

The moral, I guess, is beware of side-effects of parameters.

(This has all been pointed out elsewhere; I thought some actual references
might help stem this discussion).
-- 
Jim Patterson                              Cognos Incorporated
UUCP:uunet!mitel!cunews!cognos!jimp        P.O. BOX 9707    
PHONE:(613)738-1440 x6112                  3755 Riverside Drive
NOT a Jays fan (not even a fan)            Ottawa, Ont  K1G 3Z4