VLAs and forward references

[Tom MacDonald]

I apologize to those of you receiving this a second time.  There was
a mailer glitch somewhere and many did not receive this submission.
I know so many of you have been unable to sleep while waiting for
my response.  {%^)

============================================================================
> But I would like to see someone from Cray respond to Stephen's remark about
> difficulties in the simple prototype "float f( double a[n], int n )" if
> there should be a typedef around called n.
> 
> 	-P.

I believe the issue involves an example like the following:

	int n = 5;
	enum { t = 5 };

	void f(int a[n+t], int n, int t) {
		. . .
	}

Which `n' and which `t' are used?  The current VLA document, NCEG.91-055
contains the following change notice in the introduction:

  - The definition of variably qualified parameters more strictly
    enforces the lexical ordering rules for VLA parameters by
    requiring identifiers in VLA sizes to bind once and only once,
    for every permutation order of the parameter declarations.
    A discussion of these issues appears after section 3.5.4.3.

It is there to address this issue.  The idea is that a VLA size must
be uniquely determined by the formal parameters and file scope identifiers.
The following words are intended to make the above example a constraint
error (and, therefore, a mandatory diagnostic).

  - For each parameter declared with "variable length array" type,
    the type used for compatibility comparisons is the one that
    results from conversion to a pointer type, as in 3.7.1.  In
    each parameter-type-list involving variable length array types
    the following two conditions shall hold:

      - there must exist a permutation of the parameter-declarations
	in which a declaration is visible for each instance of an
	identifier in a size specifier, and

      - the association of identifiers with objects is determined by
	the permuted order, and two different permutations shall not
	result in different associations.

The following is from the minutes of the Cupertino meeting:

    The issue of allowing relaxed ordering of declarations within a
    parameter-type-list was discussed.  Stallman's proposal for solving
    the "forward" referencing problem within parameter-type-list's was
    also discussed (NCEG 91-034).

    In favor of preserving lexical ordering, 7.
    In favor of relaxed ordering, 7.
    Undecided, 2.

Certainly there is no clear consensus on this issue.  The above wording is
intended to allow the compiler to look at the above example as if were
declared with an old style definition, and with all possible permutations
of the parameters (which the old style permits).  The above example permits
the following permutation of the formal parameters:

	int n = 5;
	enum { t = 5 };

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

which means the `n' and `t' bind to the formal parameters.  However, the
following permutation is also permitted:

	int n = 5;
	enum { t = 5 };

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

and then the `n' and `t' bind to the file scope identifiers.  These are two
of the six permutations permitted for the three parameters.  Since the two
different permutations shown above result in a different binding a
diagnostic is issued by the compiler.

A previous Email of mine described a possible implementation.  Essentially,
during the second scan, all identifiers with *universal* type are checked to
see if they appear at file scope and in the parameter list.  If they appear
in both places then an error is issued.

Again, the idea is that this prevents confusing declarations.

Tom MacDonald
tamacray.com
uunet!cray!tam