Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: "array" vs. "&array" ?
Message-ID: <21802@mimsy.umd.edu>
Date: 12 Jan 90 23:51:07 GMT
References: <24521@gryphon.COM> <5248@buengc.BU.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 83

>In article <21764@mimsy.umd.edu> I wrote the usual.

In article <5248@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes:
>What Chris is trying to say (though I think he's been hanging around
>with Doug and Daffy too long) is:
>
>Usually when you ask for the pointer to an array you get a
>pointer to the first element of the array.

No, nope, not even loosely speaking.  When you ask for a pointer to an
array, you get a pointer to that array (in New C) or an error (in Classic
C).

>While the symbol table will hold the compiler's copy of the address
>of the beginning of the array, the data in the array obviously can
>not be stored in the symbol table.

Each element of a symbol table in the average C compiler holds:

 - the name of a variable, function, label, etc.;
 - its type (such as `array 3 of int');
 - its scope (local, file, or global);
 - its duration (static or automatic); and
 - a *RULE* for finding the object (if any).

The last is *not*, repeat *NOT*, the `address of the array'.  In particular,
if the array is local to a block, such as with

	f() {
		int array[10];

the array does not *have* an address until run-time.  The rule for finding
this array is typically something like `subtract 48 from frame pointer
register' or `add 16 to stack pointer register'.

>E.g.:
>
>	type_t *aptr, a[MAXINDEX+1];
>
>	aptr = &a;

. . . is a type mismatch error, as I have just explained at least three
times in the last week.  Use `aptr = &a[0]' or `aptr = a'.

>	if ( *aptr == a[0] )
>	    puts( "Will always print this." );

More or less.

>I can't think of anything else in the symbol table that
>would need to have its address taken, except maybe function
>names, struct names, etc., which also have defined meanings
>when the addressof operator is applied to them.  Taking the
>address of a constant is an error.

The last sentence is correct.  The address-of operator may be applied
only to objects.  (Note that `*aptr' is an object.)  In addition, in
Classic C, the address-of operator may not be applied to objects that
are arrays.  The ANSI C committee removed this (essentially pointless)
restriction.

One more time: if you have a book that purports to explain the C language,
and it says `arrays are the same as pointers', cross that part out.  If
it does not say `a pointer points to zero or more objects', add that in.
In particular, given

	type_t *aptr, array[30];

you can make `aptr' point to (the first of) 30 objects by writing:

	aptr = &array[0];

or

	aptr = array;

The latter works because in value contexts (but only in value contexts),
an object of type `array N of T' becomes a value of type `pointer to T'
that points to the first (0'th) element of that array.  If your book
does not say this, add it as well.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris