Ok, engaging lawyer mode. ISO C99 standard says, in 6.5 (2):
Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.
Failing the above rule, behavior is undefined. However, regarding initializer lists, read
this,
this question, and this
this report. Various C and C++ standards differ in their wording, and guarantees they make. Coming back to C99,
6.7.8 (19) says:
The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; ...
But then,
6.7.8 (23)
The order in which any side effects occur among the initialization list expressions is unspecified.
This example code is valid in C99 (no undefined behaviour), yet what it prints is unspecified.
#include <stdio.h>
void meh(int t[]) {
int i = 0;
int foo[] = { [1] = ++i, [2] = ++i, [0] = ++i };
for (i = 0; i < 3; i++) { t[i] = foo[i]; }
}
int main(void) {
int x[3];
meh(x);
printf("%d %d %d\n", x[0], x[1], x[2]);
}
For perl, flexibility in constructing and manipulating lists, e.g. using iterators (with their side effects) and so on, is essential quality of the language. There is no undefined behavior here. This thing quacks like a bug, it is a bug. How much speed-up do you think this buggy optimization is worth?