Interpretation of int (*a)[3]
- by kapuzineralex
When working with arrays and pointers in C, one quickly discovers that they are by no means equivalent although it might seem so at a first glance. I know about the differences in L-values and R-values. Still, recently I tried to find out the type of a pointer that I could use in conjunction with a two-dimensional array, i.e.
int foo[2][3];
int (*a)[3] = foo;
However, I just can't find out how the compiler "understands" the type definition of a in spite of the regular operator precedence rules for * and []. If instead I were to use a typedef, the problem becomes significantly simpler:
int foo[2][3];
typedef int my_t[3];
my_t *a = foo;
At the bottom line, can someone answer me the questions as to how the term int (*a)[3] is read by the compiler? int a[3] is simple, int *a[3] is simple as well. But then, why is it not int *(a[3])?
EDIT: Of course, instead of "typecast" I meant "typedef" (it was just a typo).
