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