Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peregrine.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!oliveb!felix!peregrine!mike From: mike@peregrine.UUCP (Mike Wexler) Newsgroups: net.lang.c Subject: Re: Address of array Message-ID: <260@peregrine.UUCP> Date: Mon, 24-Mar-86 14:47:09 EST Article-I.D.: peregrin.260 Posted: Mon Mar 24 14:47:09 1986 Date-Received: Thu, 27-Mar-86 00:45:08 EST References: <750@abic.UUCP> <211@dg_rtp.UUCP> <685@steinmetz.UUCP> <58@paisley.ac.uk> Reply-To: mike@peregrine.UUCP (Mike Wexler) Organization: Peregrine Systems, Irvine, Ca Lines: 101 Keywords: array, address, c, struct 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. Here is an example program an the corresponding contents of memory on a hypothetical computer. func() { int i; int *pi int **ppi; i=512; pi=&i; ppi=π return; } address contents use |-----------| 0001 | 0512 | int i; |-----------| 0002 | 0001 | int *pi; |-----------| 0003 | 0002 | int *ppi; |-----------| Note &pi and &ppi are the *CONSTANTS* 2 and 3. Corresponding to the addresses of these variables. Notice never have I said the following construct is legal. &i=pi; This is completely illegal. No compiler I know of will let you do this. > >What I suppose I'm trying to say is that a is a constant and b is a variable. The address of "a" is a constant. The address of "b" is a constant. The contents of both "a" and "b" are variable. It just happens that when you put "a" in your code the c compiler interprets it a &a. The only thing being asked for here is that &a also be a legal syntax for specifying the address of a. > >Maybe what is wanted is the for the compiler to be "clever" >and assume that if you ask for the address of a constant >you really want the constant ? Compilers already do that. All the compilers I know of are "clever" enough to handle the following code. typedef struct foobar FOOBAR; func() { FOOBAR s; FOOBAR *p; p=&s; return; } Yet some compilers can't handle the following code. typedef int FOOBAR[10] func() { FOOBAR s; FOOBAR *p; p=&s; /* should be p=s; */ return; } This(&s) is what is meant by taking the address of an array. It is perfectly reasonable construct. -- Mike Wexler (trwrb|scgvaxd)!felix!peregrine!mike (714)855-3923 All of the preceding opinions are solely those of the author and do not represent the views of any other being, sentient or abstract.