Address of array

[Davidsen]

In article <211 at dg_rtp.UUCP> throopw at dg_rtp.UUCP (Wayne Throop) writes:
>> I have noticed that different compilers treat the & operator differently
>> when it is applied to arrays.  In particular, the UNIX compiler I have
>> been using warns against it.  K&R explicitly deny its legality.
>> However, the operation seems to me to be perfectly
>> reasonable when the desired result is a pointer to the array rather
>> than a pointer to the first element of the array.
>
>I agree that C's treatment of array/function/struct addresses is
>inconsistant, confusing, and limiting.  In essence a small notational
>convenience was traded for a large consistancy headache.  I think the
>tradeoff was wrong, but I'm not sure that your proposal would clarify
>things.

I believe that to support reasonable portable code C *must* allow the address
operator on an array, even if it is not required. Consider:

prog.c:
	#include "globals.h"  /* project global symbols and types */

	foo() {
	  LOCAL m,n;

	  process(&m);
	}

globals.h:
	typedef long LOCAL[10];

================
Since LOCAL is a typedef which is an array, the programmer would not be
able to write code which would work with a legal typedef for LOCAL
unless the & operator was allowed for an array. To require special code
to handle arrays and scalars defeats the intent of information hiding,
and requires global changes to the source is a typedef is changes, for
instance, from an array to a structure.

This was pointed out to me by someone on X3J11, but I can't remember
who in order to give credit for this example.
-- 
	-bill davidsen

	seismo!rochester!steinmetz!--\
       /                               \
ihnp4!              unirot ------------->---> crdos1!davidsen
       \                               /
        chinet! ---------------------/        (davidsen at ge-crd.ARPA)

"It seemed like a good idea at the time..."