VLA proposal... one more nit (response)

[Tom MacDonald]

I have some more time to address comments about the VLA proposal.
I'm going to have to limit my time to just a few sessions a week.
I have deadlines rapidly approaching and these days VLA is just a
hobby of mine.  Besides, all my time is taken up deleting people
from the nceg list :^).

> Oops!  I just remember one more minor thing I wanted to note/ask about the
> VLA proposal which Tom M. just posted.
> 
> I didn't see anything in there about the validity of using VLA types in
> casts.  For example, would this be legal?
> 
> 	void *vp;
> 
> 	void foobar (int n);
> 	{
> 		int (*p)[n] = (int (*)[n]) vp;
> 	}
> 
> 
> // Ronald F. Guilmette
> //    domain address:	rfgasegfault.uucp
> //    uucp address:	...!uunet!netcom.com!segfault!rfg

The answer is that the cast in your example is perfectly acceptable.  I
should include an example that uses a cast.  For example, if you wanted
to develop a Transpose function that could be called from Fortran,
something like the following interface would work on a CRI system:


   void TRANSPOSE(const double *A, int NROWS, int NCOLS, const double *TA) {

      const double (*a)[NCOLS] = (const double (*)[NCOLS]) A;
      double (*ta)[NROWS] = (double (*)[NROWS]) TA;

      /* do the transpose */

   }

Now, I must admit I don't want to take the time to think too much about
row major and column major issues but you get the idea.  For us here at
CRI, this gives us the ability to develop Fortran scientific libraries
that are callable from Fortran without having to completely linearize
all the subscripts or pointer references.

The paper does not address casts specifically because the specification
of casts does not change.  The description of a cast states that unless
the type name is `void' then both it and the operand must specify scalars.
A pointer to a VLA is still a scalar.

That's the intent anyway.

Tom MacDonald