Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!cmcl2!philabs!mcnc!rti-sel!dg_rtp!throopw
From: throopw@dg_rtp.UUCP
Newsgroups: net.lang.c
Subject: Re: Pointers and Arrays
Message-ID: <452@dg_rtp.UUCP>
Date: Mon, 21-Jul-86 12:04:56 EDT
Article-I.D.: dg_rtp.452
Posted: Mon Jul 21 12:04:56 1986
Date-Received: Tue, 22-Jul-86 09:02:40 EDT
References: <1242@ncoast.UUCP> <418@dg_rtp.UUCP> <1267@ncoast.UUCP> <2201@umcp-cs.UUCP> <2206@umcp-cs.UUCP> <839@steinmetz.UUCP>
Lines: 67

> davidsen@steinmetz.UUCP (Davidsen)

> After thinking about the discussions about using the address operator
> on an array by name, I come to the reluctant conclusiont that it SHOULD
> be allowed in the new ANSI standard. [...]
>
> Reason 1: "codification of existing practice"

Well, maybe.  However, this argument means that the standard should say
that the compiler ought to warn about it, yet compile it.  An odd thing
for a standard to say.

> 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.

Second, the inability to hide information (in particular, the allowable
operators for a type) is not unique to arrays in any event.  Integers
can be "+"ed, but not structures, structures can be "."ed, but not
pointers, etc etc etc, and none of this can be hidden.  And even if "&"
were allowed, the assignment would not be.  I'll admit that "&" is a
peculiar operator to not be mostly universal, but I'm still not
convinced that C's peculiar treatment of arrays makes taking their
address sensible.  In effect, it adds yet-another-special-case, rather
than regularizing things.

> 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.

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.


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.

--
The string is a stark data structure and everywhere it is passed there
is much duplication of process.  It is a perfect vehicle for hiding
information.
                                --- Alan J. Perlis
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw