On 13/08/2020 09.42, Jens Gustedt wrote:
> Ok, good to know. I will add something along the lines to my document
> about the intersection of C and C++. It would go along the lines
>
> C and C++ differ on an important aspect concerning
> initializers. Where for C the expressions in an initializer are
> unsequenced, C++ imposes specification of the initializers in
> declaration order and sequences them according to that order. As
> a consequence
>
> - providing designated initializers in an order that is
> different from declaration order is a constraint violation in
> C++,
>
> - in C, using expressions that must be sequenced to be valid
> (such as multiple occurence of the same increment operation)
> leads to undefined behavior.
>
> It is recommended that applications that target the common C/C++
> core list initializers in declaration order. Further it is
> recommended that implementations that target that core diagnose
> situations that would be problematic for the other language,
> such as initializers not appearing in declaration order or
> initializer expressions that require sequencing.

I'd suggest to add cross-references to the respective standard's rule.
For C++, this is [dcl.init.list] paragraph 4.

> I am not too optimistic we can change this situation, though. The fact
> that initializer expressions and function argument evaluation are
> unsequenced in C is deeply built into optimizers, I think.

Note that C++ continues to have indeterminately sequenced
(but NOT unsequenced) function call arguments; see C++ [expr.call]
paragraph 8. The remaining freedom is necessary because some argument
passing conventions might do left-to-right and others might do
right-to-left. Requiring evaluation in left-to-right order may
substantially pessimize some implementations.

Jens