Variable-length arrays <9112191848.AA06750awotan.think.com>

[uunet!cygnus.com!gnu]

> I don't believe that programmers will use unprototyped functions just
> because they might allow the parameters in the other order, as follows:
> 	void f(a, n)	/* I don't believe that this construct will */
> 	int n;		/*   be used by good programmers */
> 	double a[n];
> 	{ /* body */ }

I disagree with the notion that "good programmers" will always use
function prototypes.  Any solution that assumes this has a flaw.

I write code that has to work in a wide variety of environments --
including those that have never seen the touch of ANSI.  The *only*
portable C program is one that ignores prototypes (or selects at
compile time, by using really ugly macros).  Maybe three years from
now that will be different, but it's reality today.

Function prototypes are a wart on C.  (They "solve" a previous wart,
but replacing one wart with a larger one is not usually considered
progress.)  C declaration syntax was already the most complicated,
hard to learn part of the language; function prototypes tripled
its complexity.  I hope NCEG won't triple it again by further
complicating function declarations.

While I'm in sympathy with RMS's aims, his arglist proposals tended to
have too much of the Stroustroup "hmm, let's find a character that can
never appear here, and make it mean something random" approach to
language design.  Can we try for consistency and simplicity?  It
might mean sacrificing function.  And that might be worth it.

	John Gilmore