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)