Conformant Arrays in C (a better solution?)

[Richard A. O'Keefe]

In article <662 at xyzzy.UUCP>, throopw at xyzzy.UUCP (Wayne A. Throop) writes:
> Now it seems to me that, allowing non-constant expressions in the bounds
> of formal array arguments is the minimal, conservative, non-dope-vector,
> covers-most-bases solution.  That is:
> 
>         g(){
>             double a[I][J][K];
>             f( a, I, J, K );
>         }
>         f(a,ilim,jlim,klim)
>             double a[ilim][jlim][klim]; /*currently illegal*/
>             int ilim,jlim,klim;
>         {
	      ...
>         }
> 
> ... would be made legal.  The problematic point that the type of the
> formal a isn't precisely known until runtime can be made a special case

(That's not a problematic point in my view; the bounds of an array *are*
currently regarded as part of its type, *but* that is a major design
error shared with Pascal.)

What are the differences between this and the C.A.P. proposal, other than
the fact that GNU CC is said to support it, so that this proposal *is*
prior art, and the C.A.P. proposal isn't?

(1) This is exactly the Fortran approach.  There is lots of experience
    with it, and the numerical people for whose sake the C.A.P. proposal
    was made will already be familiar with it.

(2) One of the benefits is that you can easily declare that several
    array parameters are the same size, which is not possible in the
    current version of the C.A.P. proposal.

(3) A major problem is that you can get the arguments wrong.

(4) A minor problem is that a C program may alter arguments like ilim,
    jlim, klim (though presumably lint would warn about this), so a
    compiler either has to be prepared to make a copy of them.
    Conformant array bound parameters are 'const int' by definition, so
    this problem cannot arise.

The current version of the C.A.P. proposal replaces the rather ugly '?'
marker by the alternative keywords 'auto' and 'register', so that one
would declare f in the C.A.P. proposal as

	void f(double a[auto ilim][auto jlim][auto klim])
	    {
		...
	    }

(Note that the type is implicitly 'int', and no explicit over-ride of
this is possible.)  

I think conformant arrays are cleaner than the Fortran hack, but I'd
be happy with either.