🚀 go-pugleaf

tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya) wrote:

>In article <49nbij$e1c@rdsunx.crd.ge.com>, volpe@bart.crd.ge.com (Christopher
>R. Volpe) writes: 
><snip>
>|> Perhaps you meant "i = (f(), i+i)". This is still not undefined. The
>|> expression on the right is used to compute the new value of i in the top
>level 
>|> assignment. And the subexpression on the right has a sequence pint between
>the 
>|> evaluatin of "i=1" in f(), and the evaluation of "i+i". I see nothing
>|> technically wrong with this according to the rules of the STandard.

>Is `i + (f(),i+i)' well defined? Or to focus in, is `i + (f(),1)' well
>defined? i.e. is the sequence point before and after the evaluation of i=1 by
>calling f _between_ the evaluation of the i in i + and the modification? I
>thought this issue was not resolved last time it was discussed here. 

>Is this any different from i = (f(),1)?

No, and I'm quite certain that all of these are undefined -- Chris seems
to be assuming that since the value of the right side is needed for the
assignment, that it must be evaluated first, which is to say that the
assignment operator would form a sequence point between evaluation of
the right side and the left side.  However, the standard makes no such
guarantee that I can find.  In this case, a little flow control will
allow the compiler the pre-compute the value of the right side, assign
that to i, then evaluate the call to `f ' in the right side for its side
effect, and not violate any rules I can find.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */