Variable Length Array Passing, summary of proposals

[Thomas M. Breuel]

|The storage for an automatic array is allocated just once.
|Later variable assignments can't reallocate the storage to fit.
|
|    {
|      int foo[m];
|      m *= 2;
|      ... sizeof (foo) ...   /* old m or new m? */
|      ... foo[m-1] ...       /* error! */
|    }
|
|Since changing m can't really change the size, letting it
|*appear* to change the size of foo is just a pitfall.

But "m" here is just a variable, not related in any way
to the array "foo".

In the argument notation that I proposed, 

	float foo(float a[a_m][a_n]) { a_m=3; a_n=9; ...}

the variable "a_m" would get defined by the argument declaration
and it would be used for index computations.

|tmb suggests we could treat automatic arrays one way, and arguments
|the other way.  He says there is "no conflict" because the cases
|are distinct.
|
|That is true, but it isn't the real issue.  There is no conflict--no
|single situation in which the requirements can't be satisfied.  But it
|is inconsistent because one construct would have different semantics
|in different contexts.  That is bad design.

But automatic arrays are already very different from arguments.
Automatic arrays allocate storage. Their size is determined by their
declaration. Arguments, on the other hand, do not allocate storage.
Passing a multi-dimensional array is just a fancy way of accessing some
existing data. Consider, for example:

	foo(double x[4][4]) {printf("%d\n",sizeof x);}
vs.
	{double x[4][4]; printf("%d\n",sizeof x);}

Notationally, I prefer "my" proposal to what RMS proposes, and I don't
think that programmers would have any difficulties dealing with the
construct. Most people would probably adopt a reasonable convention for
naming dimension variables, as opposed to other variables, and
compilers could (and should) warn about multiple assignments to, or
taking the addres off, dimension variables.

But I don't want to defend this proposal to the teeth. There may be
other things wrong with it than the conceptual inconsistency that RMS
sees. In fact, some notation closer to what steveataumet has proposed
is probably necessary to avoid problems with enums and other named
constants, consider: "enum {x,y,a}; foo(int x[a][a]) {}".

I mainly wanted to suggest a different way of thinking about the
problem.  In other words, is it really necessary to squeeze the
dimension expressions into the argument list? Isn't the function body
the natural place for computing them? That is, of course, if you
want to allow arbitrary expressions for the computation of array
dimensions in the first place.

						Thomas.