Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!smoke!rbj@icst-cmr
From: rbj@icst-cmr (Root Boy Jim)
Newsgroups: net.lang.c
Subject: Re: Address of array
Message-ID: <1709@brl-smoke.ARPA>
Date: Tue, 11-Mar-86 18:27:16 EST
Article-I.D.: brl-smok.1709
Posted: Tue Mar 11 18:27:16 1986
Date-Received: Fri, 14-Mar-86 06:48:59 EST
Sender: news@brl-smoke.ARPA
Lines: 32


	From: Wayne Throop <dg_rtp!throopw>
	Subject: Re: Address of array
	Date: 9 Mar 86 05:02:13 GMT
	To: info-c@brl-smoke.arpa
	
	> I have noticed that different compilers treat the & operator differently
	> when it is applied to arrays.  In particular, the UNIX compiler I have
	> been using warns against it.  K&R explicitly deny its legality.
	> However, the operation seems to me to be perfectly
	> reasonable when the desired result is a pointer to the array rather
	> than a pointer to the first element of the array.
	
	I agree that C's treatment of array/function/struct addresses is
	inconsistant, confusing, and limiting.  

I diagree violently (so what else is new?). The resolution of pointers
and arrays is one of the *strengths* of C. Admittedly there are a few
glitches, such as when the sizeof operator is applied to an array. Ironically,
this glitch was added to *help* the user. Personally, when a formal
parameter is declared as a local array, I would like to see sizeof
return the same as if it was a global.

	In essence a small notational
	convenience was traded for a large consistancy headache.  I think the
	tradeoff was wrong, but I'm not sure that your proposal would clarify
	things.  I'd hesitate to evaluate textually and syntactically identical
	constructs differently based on whether an lvalue or an rvalue is needed
	in the current context.  This would pile more confusion on an already
	dismal situation.
	
All the compilers I've seen give a warning, but generate &array[0].