multi-d arrays and types

rpjday at ccu.umanitoba.ca rpjday at ccu.umanitoba.ca
Tue Mar 27 01:53:19 AEST 1990


  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?



More information about the Comp.lang.c mailing list