Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!zen!katerina!c188-bl
From: c188-bl@katerina.uucp (Steven Brian McKechnie Sargent)
Newsgroups: comp.lang.c
Subject: Re: Address of Array
Message-ID: <5308@zen.berkeley.edu>
Date: 12 Dec 87 02:36:53 GMT
References: <126@citcom.UUCP> <2550034@hpisod2.HP.COM> <1854@haddock.ISC.COM> <532@ndsuvax.UUCP> <2020@ttrdc.UUCP> <555@ndsuvax.UUCP> <1949@haddock.ISC.COM>
Sender: news@zen.berkeley.edu
Reply-To: sarge@scam.berkeley.edu (Steven Brian McKechnie Sargent)
Organization: University of California, Berkeley
Lines: 29

In article <1949@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <555@ndsuvax.UUCP> ncbauers@ndsuvax.UUCP (Michael Bauers) writes:
>>But the address of the array's pointer (what this person wanted to know)
>>should be &a.
>
>Are you saying that "&a" should mean "&(&a[0])"?  This doesn't make sense, as
>"&a[0]" is not an lvalue.

On a "prior art" note, VAX C allows objects like &3, even though 3 is not an
lvalue.  Because VMS is ruled by Fortran, most VMS services and library entries
expect everything passed by reference, even constants: as a convenience to
C programmers calling VMS routines, the expression &3 means "cons up an
anonymous int whose value is 3; value of the expression is the address of the
anonymous int."  So &a /could/ be given an analogous interpretation, one at
variance with your preference.

>address of an entire array entity (which differs from the address of the first
>element in exactly the same way that the address of a structure differs from
>the address of its first member), and this is exactly the problem that X3J11
>has fixed by legalizing "&a".

Um, no.  Given an object, s, of type "struct s", &s + 1 does NOT refer to the
second element in the struct.  Address arithmetic just doesn't "make sense"
with structures the same way that it does with arrays.

>
>Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

Steven Sargent (sarge@scam.berkeley.edu)