pointers to arrays

[William E. Davidsen Jr]

My reading of dbANS is that the address of array has been changed, not
fixed, and is now broken in another way. Hopefully someone will
enlighten me as to what part of the standard I'm missing.

It looks to me as though given:
	int flimflam[20];
that &flimflam has type address of int. I maintain that if flimflam is
an array [20] of int, then &flimflam is "address of array [20] of int."

Consider the code fragment:
	mytype fuzzbutt, *charlie = &fuzzbutt; /* named after cats */

if I declare the typedef as:
	typedef long mytype;
everything works. If I declare it as:
	typedef struct { int xx[20]; } mytype;
it still works. But if I say:
	typedef int mytype[20];

The code fragment fails or generates a warning on most existing compilers
due to taking the address of an array. On an ANSI compliant compiler I
*believe* that there will be a warning because the address is not of the
same type as the pointer.

Arrays are barely supported in C, in that (a) taking the address doesn't
do the same thing as the address of an int or struct, (b) an array can't
be passed as an argument, and (c) a procedure can't return an array.

I couldn't see X3J11 supporting a rewrite of arrays, but I don't believe
that defining &array to return pointer to array would hurt existing
programs, they get warnings in most cases anyway.

I could be wrong about the type returned by &array, so feel free to
identify and/or interpret the standard to correct or confirm my
understanding of it.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me