(SC22WG14.323) Re: reaction to Variable Length Array Proposal <9302111813.AA14112aiecc.cambridge.ma.us>

[uunet!netcom.com!segfault!rfg]

John R. Levine writes:

>  I'd like to call some of those time-tested Fortran routines from my C
>  code, something which I expect most of us agree is a reasonable thing to
>  do.  If the Fortran code puts the array before the dimension, I can't
>  write a proper prototype for it.

I'd disagree immediately if it were not for one thing... The term "proper
prototype" is left to the imagination (and interpretation) of the reader.

For example, I *know* that you can write:

	extern /* fortran */ dusty_deck (void *, int n);

... and you should be able to pass any kind of array you like in as the
first parameter to that!

You say that's not "proper" enough for you?  You want to be sure that you
are only allowed to pass arrays of ints?  Ok.  I'll buy that.  How about:

	extern /* fortran */ dusty_deck (int *, int n);

or maybe:

	extern /* fortran */ dusty_deck (int [], int n);

You say you want to pass only 2-d arrays?  OK.  Try:

	extern /* fortran */ dusty_deck (int [][100], int n);

You say that you don't want to have to specify the length of the second
dimension.  OK.  Sounds reasonable.  We could do that with just a minor
change to the language, i.e. one which would permit us to write:

	extern /* fortran */ dusty_deck (int [][], int n, int m);

>  Even worse, consider Fortran numerical integration routines that take as
>  an argument a function to call which computes a point of the function to
>  be integrated.  I'd be pretty dismayed if lexical theology kept me from
>  writing a C routine with an appropriate argument list that I could use as
>  the integrand.

In C, you are almost never *prevented* from doing anything that you might
really need to do.  Here's one way you could write your function using the
other VLA features already discussed:

	int compute_point (void *ap, int n, int m)
	{
		int (*p)[n][m] = ap;

		/* ... use `p' from here on down for maximal type safety ... */
		/* ... */
	}
  
>  A design that lets me write "foo(n,a)" but not "foo(a,n)" will be met with
>  derision.

A concept which breaks the natural and simple lexical rules of C has *already*
met with derision.

>  I can't say that I'm overjoyed with either TAM's lexical hack
>  or RMS's forward declarations, but we need something.

People keep saying that, but just saying it doesn't make it so.  The folks
who claim this is such a necessity need to stop emoting and start providing
some hard evidence that some tangible benefits will be gained from breaking
C's lexical scoping rules (if they can find any).


// Ronald F. Guilmette
//    domain address:	rfgasegfault.uucp
//    uucp address:	...!uunet!netcom.com!segfault!rfg

// Ronald F. Guilmette
//    domain address:	rfgasegfault.uucp
//    uucp address:	...!uunet!netcom.com!segfault!rfg