Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!bellcore!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!ukc!dcl-cs!paisley!rh
From: rh@cs.paisley.ac.uk (Robert Hamilton)
Newsgroups: net.lang.c
Subject: Re: Address of array
Message-ID: <88@paisley.ac.uk>
Date: Tue, 1-Apr-86 08:37:51 EST
Article-I.D.: paisley.88
Posted: Tue Apr  1 08:37:51 1986
Date-Received: Sat, 5-Apr-86 07:18:56 EST
References: <750@abic.UUCP> <211@dg_rtp.UUCP> <685@steinmetz.UUCP> <58@paisley.ac.uk> <260@peregrine.UUCP>
Sender: rh@paisley.ac.uk
Reply-To: rh@cs.paisley.ac.uk (Robert Hamilton)
Organization: Paisley College of Technology Scotland.
Lines: 65
Keywords: array, address, c, struct

In article <260@peregrine.UUCP> mike@peregrine.UUCP (Mike Wexler) writes:
>In article <58@paisley.ac.uk> rh@cs.paisley.ac.uk (Robert Hamilton) writes:
>>
>>Taking the address of an array just doesnt make sense in C.
>>You can see the reason if you know why the following bit of
>>code also won't work:
>>int a[10];
>>int *b;
>>a=b; /* makes no sense */
>true
>>a+=1; /* ditto */
>true
>>b=a; /* ok of course */
>>
>>The decl. a[10] does 2 things:
>> 1. reserves storage for 10 elements
>true
>> 2. lets the compiler know that "a" is an int * to
>>    of the first element reserved.
>>    It does *not* reserve storage for a pointer to the storage.
>true
>Declarations never reserve storage for a pointer to the storage.  Your argument
>doesn't make sense.
>It would be useful to be able to apply the ampersand operator to any object
>without knowing what its "real" type is(it could be hiddenn by typedefs). 
>
>>So "&a" only exists during compilation, in the sense that the
>>compiler holds the address of the reserved storage somewhere
>>that "somewhere" has an address at compile time.
>>The decl. int *b on the other hand does 2 different things.
>>1. lets the compiler know that "b" is an int * ( for pointer arithmetic)
>true
>>2. and reserves a storage location for b.
>>   so &b does exist at run time.
>wrong.  This seems to be your point of confusion.  "int *b" reserves space for
>b that is correct. "b" is a pointer. "&b" is a pointer to that pointer.  They
>are not the same.

NO you misunderstand me.
My argument is a valid explanation of why C rejects the address of an array
(at least in my interpretation of what EXISTS means)
If storage is reserved for b then that storage must have a runtime address
must it not ?? And so that address is &b and can be taken as rhs.
You say so yourself :
>int *pi;
>int **pi=&pi; /**/

I don't of course mean that &b is some value sitting somewhere in memory
so you cant take the &b as a lhs .(as you say)
In the same way (int a[10]) sits in memory somewhere and has an address a
so you can say int *b=a which also happens to be &a[0].
But a itself does not sit in memory (as b does) and so &a does not exist.

The pointer/array confusion comes because
C takes a to be the address of the array rather than the array itself,
which is inconsistent with the treatment of everything else.

But enough of this, I do see the problem and agree...
-- 
UUCP:	...!seismo!mcvax!ukc!paisley!rh
DARPA:	rh%cs.paisley.ac.uk		| Post: Paisley College
JANET:	rh@uk.ac.paisley.cs		|	Department of Computing,
Phone:	+44 41 887 1241 Ext. 219	|	High St. Paisley.
					|	Scotland.
					|	PA1 2BE