statement expressions and extended asm bug?

[Segher Boessenkool]

>>>     static inline void increment (int * ptr) { *ptr++; return 0; }
>>>     func (increment (&a), increment (&a));
>
>> No, it is just as undefined.  The compiler is free to call
>> either the "left" or the "right" increment() first.
>
> Why is this undefined? Isn't it just unspecified? If I understand
> the DR Joseph pointed me too, the order of the two function calls
> is unspecified, but they do not overlap and there is a sequence point
> just before each call (after the arguments have been evaluated), and
> a sequence point before each returns.

Yes, I overlooked the fact that increment() always return 0, instead
of the value of *ptr++.  So either order the arguments to func() are
evaluated, you get the same values, so this is fine.  (with the
obvious s/void/int/ , of course).

It's just the same as

	increment(&a);
	increment(&a);
	func(0, 0);

> The original stmt-expr problem is more akin to the following (if 
> stmt-exprs
> were to produce rvalues in a return-like way),
>   int var;
>   static inline int frob (int x) {var = x; return var;}
>   func (frob (12), frob (13));
> Are you saying this is undefined too?

The return values of the two "calls" to frob() are not
dependent on the order of those calls; so no.

Sorry for the confusion.


Segher