Path: utzoo!attcan!uunet!van-bc!ubc-cs!alberta!ccu!rpjday From: rpjday@ccu.umanitoba.ca Newsgroups: comp.lang.c Subject: multi-d arrays and types Message-ID: <1990Mar26.155319.23986@ccu.umanitoba.ca> Date: 26 Mar 90 15:53:19 GMT Organization: University of Manitoba, Winnipeg, Canada Lines: 47 Consider the following snippet of program, involving a 2-d array for a calendar. int calendar[12][31]; int (*monthptr)[31]; Clearly, calendar is a 2-d array in the sense that ANYTHING in C is a 2-d array, since all arrays in C are technically 1-dimensional. Based on my understanding of arrays in C, what calendar is is a 1-d array, whose elements themselves are arrays of length 31 of integers. Right so far? OK. The variable "monthptr" is now declared as a pointer to an array of length 31 of int, which SHOULD match with the type of element of the array calendar, no? Based on this, I write a loop to scan the elements of calendar, the outermost loop looking like for (monthptr = calendar; monthptr <= calendar[11]; monthptr++) { ..... } My assumption is that the first assignment should not be a problem, as we have a pointer being assigned the name of an array whose elements have EXACTLY the same type as the pointer. This, in fact, works. "monthptr++" also works as address arithmetic increments monthptr by the length of an int[31]. The weirdness is in the comparison which, while it works, complains that the types are incompatible ("warning: illegal pointer combination"). Putting an "&" in front of "calendar[11]" makes it even worse as the compiler complains that I now have "& before array or function", tosses the "&", then generates the first warning. The question is, just what the heck type is "calendar[11]"???? It seems to me that what I am seeing is some sort of schizophrenic behaviour. "calendar[11]", on the one hand, is an element of an array, so I should be allowed to apply "&" to it. On the other hand, it is itself an array so I shouldn't need the "&" in front of an array. Making things explicit and using "(int (*) [31]) calendar[11]" finally makes the compiler stop complaining, but this doesn't get me any closer to figuring just what type this is, if it isn't already an "int (*) [31]". Comments?