variable length arrays and function definitions

[Tom MacDonald]

> Could you possibly tell me the names and addresses of the people who
> did not like my proposal for a new function definition syntax?
> 
>     int foo (a, n; int n, double a[n])
>     int foo (a, int n; double a[n])
> 
> I would like to talk with them to find out what they don't like,
> so I can try to convince them.

In looking through my piles of backed up Email I came across this
message from Richard Stallman.  Sorry to take so long to respond
(seems like I say that more and more these days).  I do not like
this proposal (but I could be convinced otherwise) primarily
because it is does not cleanly express the argument information
that a function accepts.  Consider the following example:

Example 1
---------

	typedef int a;

	int foo (a, int n; double a[n]);

It seems to me that this function prototype contains some
ambiguities in that it is unclear if `a' is a type name that
starts a prototype or a parameter name that is completed later.
If the parser needs to scan to a `;' or `)' that terminates the
declaration in order to disambiguate the parameters, then it is
not much better than:

Example 2
---------

	typedef int a;

	int foo (double a[n], int n);

and resolving the number of elements of array `a' with parameter `n'.
Example 2 is easier for a human to read and the ambiguity disappears.
Example 2 does compromise C's sacred lexing rules however.  Example 1
is harder to read IMHO.

Here is a quiz - What output should be generated from the following:

	#include <stdio.h>
	 
	enum { n = 5 };

	void f(int [][n], int);
	 
	void f(a,n)
	   int a[n][n];
	{
	   unsigned long ul = sizeof(*a) / sizeof(int);
	   printf("n = %lu\n", ul);
	   printf("n = %d\n", n);
	}

	main() {
	   f(0,n);
	}

lexical-order-is-a-trick-ly yours,

Tom MacDonald

p.s.  gcc gets it right!