Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!rti!xyzzy!throopw
From: throopw@xyzzy.UUCP (Wayne A. Throop)
Newsgroups: comp.lang.c
Subject: Re: Address of Array
Message-ID: <472@xyzzy.UUCP>
Date: 17 Dec 87 21:48:23 GMT
Organization: Data General, RTP NC.
Lines: 133

> References: <555@ndsuvax.UUCP>
> ncbauers@ndsuvax.UUCP (Michael Bauers)
> What they
> had meant to say I think was 'The adress of the array's pointer.'  

No, they really meant the address of the array.

> The article
> I was responding to was talking about taking the address of an array.  The
> address of the array a[10] is just a.

This is incorrect.  Detailed discussion below (which I hope hits a few
points not already covered by others).

> References: <126@citcom.UUCP> ... <3137@tut.cis.ohio-state.edu>
> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani)
>>, marty1@houdi.UUCP (M.BRILLIANT)
>> That says there's no such thing as &a.
> This is like taking the address of a constant, say &0435241250,
> which of course is silly.

This is common folklore, that "arrays are constants" or "array names
represent constants".  This is true, but only for an unusual meaning of
the word "constant", involving "unchanging for a specific (but possibly
varying) lifetime".  "Constant" things are more normally thought of as
being unchanged at least as long as a process execution, normally
longer, and this is not true of arrays.

The address of the first element of a particular instance of an array is
a value that does not change for the lifetime of that instance of that
array.  But that's not the same thing as a "constant", at least, not as
most people think of constants.  Think of automatic arrays, for example.

By the way, the draft X3J11 standards document has changed the standard
way of talking about arrays.  In the terms as defined in the document,
it is incorrect to say that arrays are "constants", or that array names
evaluate to constants, or any of those common sayings.  In fact, arrays
are even lvalues as the term is defined in the standard.  (It turns out
that "lvalue" will no longer mean "may be assigned to".  Arrays are
examples of "non-modifyable lvalues".)

> Why do programmers want to do this?

It is most useful in dealing with arrays of arrays, or in dealing with
heaplike allocation of array objects.

> Do other
> languages let you do this?

Yes.  Pascal, Modula, PL/I (sort of), and more less-famous Algol
variants than you can shake a stick at.


> References: <329@dlhpedg.co.uk>
> cl@dlhpedg.co.uk (Charles Lambert)
> Any object, of any type (integer, structure, array, etc.), has an address.

Right.

> Usually, if it is an object that occupies several words of memory, it is the
> address at which it begins.

Wrong, at least if you are talking about how addresses are treated in C.
There is no such thing as "begins" and "ends" in terms of addresses of C
objects.  There is just the address of the object, period.  See my note
about the usage of the term "address" in the C language below, in
response to Doug Gwyn.

> In C,  the address of an array is the same as the address of its first
> element (array[0]).

No.  Because the address of the array and the address of the first
element *IN* *C* have different results when indirected or incremented.

> If you want to set up a pointer to the array, you
> get its address simply by naming it. Hence:
> 	pa = array;	/* pa now contains the address of "array" */

No.  Unless a type conversion not shown is implied by the assignment, pa
contains the address of the first element of array.

> Now this is a slight quirk in C - the name of the array being a synonym for
> its address;

This is not a quirk of C.  The name of an array is a synonym (but not
always) for the address of its first element, not for the whole array.
The two are distinct things.  K&R are very careful here, they do *NOT*
say that the name of an array is a synonym for that array's address.

> So we get back to the discussion from whence we came: why can't we be
> consistent and get the address of an array by
> 	pa = &array;	?
> To which the answer is:  you can, with some compilers.

But most often, compilers that allow this construct do it incorrectly,
and make it a synonym of 

        pa = array;

which is, of course, incorrect.  ANSI C compilers will get this correct.

> References: <6835@brl-smoke.ARPA>
> gwyn@brl-smoke.ARPA (Doug Gwyn )
> As Chris Torek remarked, "address" should not be bandied about
> when talking about C; C is a typed language, and its pointers
> have definite types.  Understanding the &array issue requires
> being careful about type distinctions.

Actually, K&R sort-of use "address" and "pointer" to refer to
indirectable-and-arithmetic-able rvalues and lvalues respectively.
Thus, I don't think it is wrong to talk about "addresses" in C.  But
you'd better remember that you aren't talking about address-of-anything.
In C, you are talking about address-of-something-in-particular.  (Yes,
I'm ignoring (void *) and function pointers for now.  So sue me.)

Remember, in C, "address" is a technical term, just as "pointer" is.
Or at least, that's the way I tend to use it.

> References: <15869@watmath.waterloo.edu>
> rbutterworth@watmath.waterloo.edu (Ray Butterworth)
> Isn't it amazing how many people are confused by such a simple
> concept as the address of an array?  If only K&R hadn't tried
> to "optimize" out this idea, I don't think there would be any
> of this confusion (at least no more than there is for the
> concept of the address of a structure).

Hear, hear!

--
"Technical term" is a technical term for a common word or phrase whose
meaning is, in some contexts, distorted beyond mortal comprehension.
                                --- Hal Peterson ihnp4!cray!hrp
-- 
Wayne Throop      !mcnc!rti!xyzzy!throopw