Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!caip!brl-adm!brl-smoke!smoke!rbj@icst-cmr
From: rbj@icst-cmr (Root Boy Jim)
Newsgroups: net.lang.c
Subject: Re: Pointers and Arrays
Message-ID: <2504@brl-smoke.ARPA>
Date: Wed, 23-Jul-86 13:13:16 EDT
Article-I.D.: brl-smok.2504
Posted: Wed Jul 23 13:13:16 1986
Date-Received: Thu, 24-Jul-86 03:44:13 EDT
Sender: news@brl-smoke.ARPA
Lines: 63


	> davidsen@steinmetz.UUCP (Davidsen)
	
	> Reason 2: "modularity and information hiding"
	
	Unfortunately this argument doesn't hold up, for two reasons.  First,
	&array (when it is allowed) currently most often evaluates to the
	address of the first element of the array, not to the address of the
	whole array.  Thus, you can't hide the array-ness anyhow, since this is
	different than other applications of the & operator.

Hopefully, the first element is at the same address as the entire array.
	
	Second, the inability to hide information ...

I pretty much agree, but then we're talking data type. I don't care
what I get back from localtime; I just want to pass it to ctime.
	
	> Reason 3: "common sense"
	> After five years of teaching C, I have to agree with my students that
	> it makes no sense to forbid this construct. To take the address of
	> something use the address operator.
	
	I have a great deal of sympathy for this view.  But NOTE WELL, that it
	should yield the address of the WHOLE ARRAY, and NOT the address of the
	first element of the array.  This is DIFFERENT than current usage.  Note
	that it would make
	
	        int actual[10];
	        void f(formal) int formal[10];{}
	        void g(){ f(&actual); }
	
	type-incorrect, since the formal is expecting type (int *), and gets
	type (int (*)[]) instead.

If you think about it, a pointer to an int can be used (and is) as a pointer
to an array of ints. Unless you apply ++ to it, they are the same thing.
(I can already feel the flames approaching).
	
	Also note that "to take the address of something, use the address
	operator" is overly simplistic, even if arrays could be "&"ed.  There
	are many "somethings" that cannot be "&"ed, such as register variables,
	bit fields, expressions, and so on.  Arrays happen currently to be one
	of these.
	
Taking a larger view, while I think that it's relatively harmless, except
for macros, there's no compelling reason to clamor for this either. On the
other hand, compilers should warn about but ignore the `&' as that's what
the guy probably meant anyhow, and he shouldn't have to recompile just for that.

	To sum up, I wouldn't be absolutely aghast if ANSI legislated that
	&array should work.  But NOTE WELL that it would constitute YASC, and it
	would be a crime against reason to make it work as it does in some
	compilers now, such that &array gives a conceptually different type than
	&non_array.  And, on balance, I'd say it isn't really that good an idea.

Yeah. Who cares?
	
	Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw

	(Root Boy) Jim Cottrell		<rbj@icst-cmr.arpa>
	I hope I bought the right relish...zzzzzzzzz..."