Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rlgvax!hadron!jsdy
From: jsdy@hadron.UUCP (Joseph S. D. Yao)
Newsgroups: net.lang.c
Subject: Re: Address of array
Message-ID: <313@hadron.UUCP>
Date: Mon, 17-Mar-86 21:15:31 EST
Article-I.D.: hadron.313
Posted: Mon Mar 17 21:15:31 1986
Date-Received: Fri, 21-Mar-86 05:24:11 EST
References: <750@abic.UUCP> <2293@utcsri.UUCP>
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Lines: 57

In article <2293@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes:
>In article <750@abic.UUCP> jst@abic.UUCP (Shack Toms) 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 it is really a design flaw in the language, to make
>it illegal to form a pointer to an array. & should work on any
>'object' ( an object of known type residing in memory at a computable
>address ) where an object is an lvalue or an array.
>...

I don't think it's reasonable to call this a flaw.  In fact, most
C compilers of which I am aware will tacitly (or sometimes with
noisy complaint) accept &array_name to be identical to array_name.
The problem is, an array name is often used as a _constant_ of type
pointer-to-______.  You cannot take the address of other constants
(e.g. &1).  It might be nice to generate an object containing the
constant, and take the address of that; but that's for more complex
and unmanageable languages than C.

[Gentle reader:  before flaming me down to slime, please stop and
think how this -- admittedly slightly off-beat -- model of an array
name fits the usage, and how it might be a nice alternative view to
your own.]

The history, of course, is that in early C only atomic objects could
be manipulated in single operations, like assignament or function
arguments or returns.  An array is not an atomic object.  A pointer
is.  Therefore, when you needed to use an array name as an atomic
object, you had to coerce it to a constant of type ptr-to-___.  A
few obvious inconsistencies show up that are a result of this:
	int x[5];
	sizeof(x) == 5*sizeof(int), because we are referring to
	the array as a whole;
	sizeof(x + 1) == sizeof(int *), because to add we have to
	coerce it to pointer, etc.
and, of course, when passed as an argument only the address strains
through.

I don't really see what the problem is that people are moaning
about.  If you want a pointer to the array, the array name itself
coerces to a pointer containing the memory location at the beginning
of the array.  There is no such thing as a pointer to the whole
array:  that is a Pasqualische or Fortranian notion.  Pointers, in
C, only point to atomic or aggregate (structure/union) objects.  I
whole-heartedly agree that for some uses it is rather nice to use
such things.  That is why (excuse me while I put on my flak jacket
and asbestos suit) C is not the only language in the world worth
using.

(Just, almost.)
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}