🚀 go-pugleaf

In article <49qiu7$25h@natasha.rmii.com>, jcoffin@rmii.com (Jerry Coffin) writes:
>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? 

It must yield one of two values, in an unspecified way, depending on which of
the two operands of the top-level "+" is evaluated first. (I've lost some
context here, but I assume f() modifies i.) I wouldn't call this
"well-defined", but it does not invoke undefined behavior either.

>>Or to focus in, is `i + (f(),1)' well
>>defined? 

Same answer. It depends on order of evaluation, so it yields an unspecified
result,  but it does not violate any shall-rules in any semantics sections.

>>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

Huh? I think the definition of "sequence point" requires the modification to
occur between those two sequence points. I'm not sure what you're asking here.
It seems pretty clear to me that the evaluation of "i" in "i + ..." occurrs
outside the sequence points that delimit the modification of i. Whether it
comes before or after is unspecified, but it does not occur within.

>>thought this issue was not resolved last time it was discussed here. 
>
>>Is this any different from i = (f(),1)?
>
>No, 

I'm going to assume that "i" starts off with the value 0, and f() increments i.
If I am not recalling the context correctly, let me know. Anyway, that above
expression looks completely well defined to me. At least, the modification in
f() is completely isolated by sequence points, so the worst it can be is
"unspecified". 


>and I'm quite certain that all of these are undefined

I can see the possibility of an argument for the unspecified case, but where
is the argument for the undefined case?

 -- 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.

No. I am well aware that the assignment operator forces no such sequence
point. Otherwise "i = i++" would be well defined, and I do not claim that.
Requiring the right hand side to be evaluated *before* the assignment is made
does not imply that a sequence point separate the two. In this case, we don't
need a sequence point from the assignment, because we have one bounding the
function call. 

What is the purpose of the sentence, "Furthermore, the prior value shall be
accessed only to determine the value to be stored"? Why not simply state, "the
object shall not be modified and have the prior value accessed between the
same pair of sequence points"? The reason is to distinguish expressions like
"i = i+1" from expressions like "++i + i", the assumption here being that in
the former case, the *evaluation* of the RHS must occur strictly before the 
modificiation to i on the LHS. Note that this does not imply that *side
effects* of the  RHS must take place before the modification of i on the LHS,
because that would require a sequence point. Rather, only the evaluation of
the RHS must occur before the modification. This is just a formal way of
stating the intuitively obvious: that you must know what you're  going to
write before you write it.

But now we have another complication thrown in. The evaluation of the "1" on
the right side of the comma operator in the expression in question must occur
before the top-level i modification, based on the above principle. But we also
have, as a result of the semantics of the comma operator, that the evaluation
of f() must occur STRICTLY PRIOR to the evaluation of the "1", and hence the
top level modification of "i". And either the sequence point  inherent in the
function call, or the sequence point associated with the comma operator, is
enough to guarantee that the modification of i within f() must be complete
before the top level modification of i. 

So no, I do not assume a sequence point inherent in the "=" operator. But the
principle of "knowing what to write before you write it" implied by the
"Furthermore,..." clause in 3.3, combined with the semantics of the comma
operator and the sequence points associated with function calls make this 
expression well defined. 

>  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.

It appears to violate the semantics of  the comma operator to me. To
"precompute the value of the right side", one must evaluate the right operand
of the comma operator, because that's where the value of the  right side comes
from. And if you evaluate the call to f() after that, you've just broken the
semantics of the comma operator.
--

Chris Volpe				Phone: (518) 387-7766 (Dial Comm 8*833
GE Corporate R&D			Fax:   (518) 387-6560
PO Box 8, Schenectady, NY 12301		Email: volpecr@crd.ge.com