[cpp-threads] RE: Initial comments on your straw man

[Jason Merrill]

Hans Boehm wrote:
> Which one of the following is legal?
> 
> (i = 13) + (i = 14)	-- no
> (i = 13) + f(&i)	-- not a clue
> f(&i) + f(&i)	-- yes, otherwise lots of stuff is broken
> 
> Probably the middle one should be undefined, but I have no idea how the
> standard implies that without also outlawing the last one.

Clause 5:

"Between the previous and next sequence point a scalar object shall have 
its stored value modified at most once by the evaluation of an 
expression. Furthermore, the prior value shall be accessed only to 
determine the value to be stored."

So both lines 2 and 3 are well-formed by themselves. But #2 is undefined 
if f either reads or modifies 'i', and similarly #3 is undefined if f 
modifies 'i' in one call and reads or modifies it in the other.

Nick Maclaren wrote:

 > Sequence points are far more messed up than THAT.
 > Consider f(g(),h()) or g()+h() and ask about the ordering of
 > the function executions g() and h().  The consensus is that
 > there is a sequence point between them, but there is no
 > ordering relation.

Not exactly. There isn't a sequence point between them. As I understand 
it there are sequence points within the call subexpressions, both before 
and after the calls, but since there is no ordering relation none of 
these sequence points can be said to be between them. A sequence point 
within a subexpression does not impose any ordering on its containing 
expression.

 > It also fixes the following problem:
 >
 >     tail = work[tail] = i;
 >
 > In C, that is technically illegal, but there is a LOT of code that
 > does it, and only a really weird implementation would get it wrong.
 > Just like a[a[0]] = k;

I don't see how it's technically illegal. The access in work[tail] is 
used to determine the value to be stored, so all is well.

Jason