Converting FORTRAN to C

[David Herron, NPR Lover]

[ I don't write until I supply stuff I am talking about ... ]

> From: dgary at ecsvax.UUCP (D Gary Grady)
> Newsgroups: net.lang.c,net.lang.f77
> Subject: Re: Converting FORTRAN to C
> Message-ID: <396 at ecsvax.UUCP>
> Date: Wed, 19-Dec-84 10:13:26 EST

> <>
> There is a real problem in converting FORTRAN to C, because there is one
> FORTRAN feature that is widely used and not duplicated in C:  the
> ability to pass varying-sized arrays as parameters.  That is, the
> following is not legal C, but the equivalent is legal FORTRAN:

Does C not allow this?  Gee, what about that BASIC interpretor I wrote
a year ago that used arrays of int (varying size) to store the intermediate
code?  These arrays got passed to most of the routines in the interpretor.
My code worked too.

> C:				FORTRAN:

> subr(array, size)		SUBROUTINE SUBR(ARRAY,ISIZE)
> int size;			INTEGER ISIZE
> float array[size][];		REAL ARRAY(1,ISIZE)
> { ...				...
> }				RETURN
> 				END

> (I don't believe C formally specifies the order of array elements, but
> in practice the row-major form is used, I think.  FORTRAN, of course,
> stores column-major.)

There ARE a number of implied pushes to this storage format.  I just checked
the proposed standard on this.  No specific mention (that I could find) was
made, BUT....  There was a discussion on initializers.  A pertinent
example from the text is:

	float y[4][3] = {
		{ 1, 3, 5 }, { 2, 4, 6 }, { 3, 5, 7 },
	};

	is a definition with a completely bracketed initialization:
	1, 3, and 5 initialize the first row of the array object
	y[0], namely y[0][0], y[0][1], and y[0][2].  Likewise the
	next two lines initialize y[1] and y[2].  The initializer ends
	earli, so y[3] is initialized with 0's.

	[page 41, edition as of October 17, 1984]

Which certainly isn't proof, but at least implication of proof.

Proof is of the form of a long winded preaching on C.

You will remember that an array is nothing more than "const int *x",
where x points at a block of memory that is the array.  The notation
of "int x[3]" => "const int *x" is extended recursively for arrays
with more dimensions.  ("int x[3][5]" => "const int *x[3]").  Meaning
that a two dimensioned array is actually a one dimensioned array of
int *'s to one dimensioned arrays of ints.  This builds as you build
deeper levels of indexing.

My contention is that this *forces* row-order storage of arrays,
(at least in the old notion of arrays).  This actually is a qualitatively
different way of thinking about arrays that isn't quite compatible
with older ways of thought.

> It is possible to pass variant-sized arrays in C by passing an array of
> pointers to arrays, or by simulating a 2-dimensional array by means of a
> one-dimensional one (handling the subscript computation with a #define
> or a subroutine would be easiest here).  But I would like to see this
> simple feature added to C; I doubt it would break any existing programs.

Why is this important?  The compiler doesn't need to know how big arrays
are, it has a pointer to its base and the size of each element.  Only
if the compiler is doing code for range bounds checking would that be
important.  Otherwise the code can be written to check array bounds
by hand.  (allowing for more efficient bounds checking.  Rather than
it being done for each reference it only has to be done for *unsure*
references.)  You are already passing in the size of the array.....
so your calling program doesn't change.

Break existing programs?  Any program that is referencing outside
the bounds of an array is already broken, and should be shot on
sight. :-)  (unless it can give good reason for behaving in such a manner).

> D Gary Grady, Duke University Computation Center (dgary at ecsvax)
> {...!(ihnp4,decvax,etc)!mcnc!ecsvax!dgary}

> -- 

> D Gary Grady
> Duke University Computation Center, Durham, NC  27706
> (919) 684-4146
> USENET:  {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary

[why do people sign things twice?]
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:-
David Herron;  ARPA-> "ukma!david"@ANL-MCS
(Try the arpa address w/ and w/o the quotes, I have had much trouble with both.)

UUCP          -:--:--:--:--:--:--:--:--:-          (follow one of these routes)

{ucbvax,unmvax,boulder,research} ! {anlams,anl-mcs} -----\  vvvvvvvvvvv
							  >-!ukma!david
   {cbosgd!hasmed,mcvax!qtlon,vax135,mddc} ! qusavx -----/  ^^^^^^^^^^^