It is easy for people who understand the relatively strong correlation between C and the assembly language it generates to assume such things work. Also, compiler vendors did let us get away with them for many years.
#include <stdio.h>
typedef float xform_3d[4][3];
int main() {
xform_3d x = {
{1.f, 0.f, 0.f},
{0.f, 1.f, 0.f},
{0.f, 0.f, 1.f},
{0.f, 0.f, 0.f} };
for(int i=0; i<12; i++) printf("%f\n", x[0][i]);
}
xf.c: In function ‘int main()’:
xf.c:12:50: warning: iteration 3u invokes undefined
behavior [-Waggressive-loop-optimizations]
for(int i=0; i<12; i++) printf("%f\n", x[0][i]);
^
xf.c:12:5: note: containing loop
for(int i=0; i<12; i++) printf("%f\n", x[0][i]);
^
Edited to add: and when built and run, it printed all x[0][i] but x[0][0] as 0.0, so gcc did emit code that doesn't do what the programmer wants.
I would suspect otherwise. I have no particularly good reason for that, but the cases with and without warnings match to my expectations of what's valid and what's not. Intuitively, I'd expect pointers can point to any valid memory, while array accesses can only be done within the dimensions of the array.
Neither variant is picked up as illegal at runtime by -fsanitize=address and gcc-4.9 or clang-3.5.
In the "pointers are just CPU registers" world, this worked fine. But more clever compilers know that the code dereferences past the end of the array (e.g., memory at f[4] is always accessed) so the whole loop is undefined behavior.
We fixed it once we started seeing the compiler warning, so I don't know exactly how we would have been punished for the undefined behavior in this case. So hooray for compiler warnings!