Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Address of Array
Message-ID: <1854@haddock.ISC.COM>
Date: Thu, 3-Dec-87 16:56:56 EST
Article-I.D.: haddock.1854
Posted: Thu Dec  3 16:56:56 1987
Date-Received: Mon, 7-Dec-87 06:30:00 EST
References: <126@citcom.UUCP> <2550034@hpisod2.HP.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 36
Summary: formal argument notation is a major stumbling block

In article <2550034@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes:
>I propose the syntax "a[]" to refer to an lvalue which is the entire array a,

Okay so far.

>and "&(a[])" to signify the address of the entire array a.

Unnecessary, since ANSI has blessed the simpler syntax "&a".

>In order to declare a formal parameter of an array type, one would have to
>supply the dimension in the brackets, since otherwise the size would be
>unknown:
>    int (bubblesort(array, n))[MAX]  int array[MAX], n;  { ... }

Nice try, but a formal argument declared "int array[MAX]" is already legal,
and it means the wrong thing.  (It's a backwards way of declaring a pointer.
Cf. "char *argv[]", which really means "char **argv"; this is true even if you
specify an explicit size.)

As of the Oct86 Draft (and presumably the latest one, too), this was to be
true even in prototype notation:
    void foo(int array[MAX]) { ... }
doesn't do the "right thing" either.  This is the first thing that needs to be
changed; otherwise it will be nearly impossible to ever make arrays into
first-class datatypes.

The very first step, then, must be to ask ANSI to *forbid* array-typed formal
arguments (as opposed to having them denote pointers).  This would not break
any existing code, because it would only affect prototypes, not old-style
declarations.

It's too late for me to have any influence on this decision, but if any of you
have already submitted official proposals on this issue, you may still have a
chance to stop ANSI from digging itself into this hole.

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