VLA's

[Tom MacDonald]

> Three comments:

Thank you for your comments.

> 	- First, just because you've been attacked by so many responders on
> 		the "backward scoping" issue, let me add one voice of support.
> 		In fact, I'd even be willing to see some existing, if highly
> 		unlikely, code, like:
> 
> 			enum something n = value;
> 			int f(int a[n],int n) { ... }
> 
> 		change in meaning (I'll send a free home-backed cookie to any-
> 		one who can demonstrate the actual existence, in real code, of
> 		such a construct) since one can then give a much simpler
> 		definition of how VLA's work, as follows.  A VLA that appears
> 		in a prototype is to be considered incomplete until we reach
> 		the closing paren.  At that point, all "pending" VLA's are
> 		completed using the then-current bindings of identifiers they
> 		refer to.  This eliminates any notion of back-referencing, and
> 		also can be read to disallow:
> 
> 			g(int a[sizeof(b)],int b[sizeof(a)]);
> 
> 		or anything similar (since it applies sizeof to an object of
> 		incomplete type).  This eliminates the need for yet another
> 		special-case rule in the proposal.

I agree with you that there are no programs (excluding compiler test suites)
that use enum constants this way.  Many compilers break on the following
testcase:

			enum { n = 10 };

			void f(n,a)
			   int a[n];
			   int n;
			{  }

which according to my reading of the C standard is perfectly acceptable.
But who cares if they break, it really serves no purpose to allow such
a creature.

The `sizeof' operator causes the most trouble.  I think a rule such
as the operand of `sizeof' doesn't have it's scope extended goes a
long toward eliminating these problems.  It seems like an example
such as:

	void f(int a[sizeof(*b)][sizeof(*b)], int b[10][10]) { ... }

isn't very useful either.


> 	- I see no reason to forbid VLA's as the LAST things in struct's.
> 		In fact, this would provide a clean way to specify the old
> 		"variable length node" hack (a struct with a trailing array
> 		with a declared length of 1 but a larger allocated length).
> 
> 		Note that in this case offsetto is no problem.

The only concern I have here is embedded structs.  You now need to have
a rule that if struct A contains a VLA, then the VLA must be last memeber,
and if a containing struct contains struct A as a memeber, that member
must be last.  There are issues some concerns about:

	struct A x[n][n];

	x[i][j].VLA[k];

It can be done.  I'm just not ready to tackle it yet.  It also becomes
hard to pass a struct with a VLA memeber to a function.  Specifying
the prototype is the hardest part.

	void (int n, struct tag { int a[n] } xyz)

This raises type compatibility questions because you have to pass a
local struct.

The `offsetof' macro isn't an issue unless you try to get the offset of
an arbitrary VLA element.

> 	- Similarly, I see no problem with VLA's in unions, and I'll even
> 		propose a situation in which it could be valuable.  Suppose
> 		we need to handle tree nodes which may contain either a
> 		single value (leaf node), or some unknown number of pointers
> 		to other nodes.  A bound on the number of pointers will only
> 		be available at run time.  A natural way to declare a type
> 		for such a node is as a union of the leaf types with a VLA
> 		of pointers, whose size is taken from an appropriate identi-
> 		fier.  sizeof and malloc then work directly; you don't have to
> 		ignore sizeof and do all the calculation yourself.
> 
> 							-- Jerry

I agree that it is useful.  I have had many users tell me that they
want VLAs in structs and unions.  The GNU C compiler has implemented
them.  I'd like to add them someday, but I'd like to make sure that the
rest of the proposal is accepted first before trying to tackle some
of these sticky issues.

Thank you for your comments.  It's nice to hear from those that like
the relaxation of the lexical ordering rules too.  I have had others
send me private mail saying it was fine with them too.  I'm sure it
will be be the subject of lively debates for a while yet.

Take care.

Tom MacDonald
tamacray.com
uunet!cray!tam