From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Adjustable arrays
Date: 6 Oct 92 23:33:33 GMT
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: cpaulse@magnus.acs.ohio-state.edu's message of 5 Oct 92 17:18:33 GMT

In article <1992Oct5.171833.16706@magnus.acs.ohio-state.edu> cpaulse@magnus.acs.ohio-state.edu (Chris D Paulse) writes:

   In some code I'm trying to modify, there are declarations within subroutines
   for arrays of size 1, for instance

	 dimension v(1)

   These arrays seem to be ajustable, as elements with indices greater than 1
   are referenced within the subroutine.  Obviously, the declaration facilitates 
   the correct addressing of the beginning of the array.  I can't seem to find
   any reference to this sort of programming in the standard fortran texts.
   Could someone please explain what is going on here?  For each of the arrays
   declared, I want to add another dimension.  Should I make the adjustable
   dimension the last one?  Any help would be welcome.

First, lets make sure we're talking about the same thing.

If an array with such properties is a dummy array (i.e. passed in by a
caller), and if the upper bound (I in DIMENSION V(I) or DIMENSION V(0:I),
for example) is a constant expression such as 1, and if it's clear that
the subprogram references elements of the array with indexes exceeding
that upper bound for the last dimension, then (big breath)...

...you have a "pseudo" adjustable array, for lack of a better term.

There are two things you should do with it:

1.  If it is possible to determine, for a given invocation, the upper
    bound of the last dimension by evaluating an expression whose
    variables are all dummy or COMMON variables for the subprogram, then
    you want to put that expression in place of the constant, which makes
    the array "adjustable":

        DIMENSION V(N*2)

    This would mean the subprogram references nothing other than elements
    1 through N*2 (where N is either another dummy like V or in COMMON).

    It does not matter if, during execution of the subprogram, the variables
    used in the expression are changed -- their initial values on each
    entry to the subprogram are used.

    This should have no impact on (optimized) program performance, but
    will prevent compilers from complaining about array-bounds errors
    either at compile or run time unless they are _real_ errors (i.e.
    referencing N*2+1) or the incoming array isn't as big as the subprogram
    claims.

2.  If you cannot determine such an expression, or you haven't the time,
    replace the upper bound of the last dimension with "*", which makes
    the array "assumed-size":

        DIMENSION V(*)

    This'll prevent any bounds-checking from being done, but is not as
    good as #1 since it is less clear to everyone (readers and compilers)
    what is really going in.  It's kind of a "by faith" thing, but still
    better than DIMENSION V(1).

And if you want to add dimensions, add them to the left as "more
significant" dimensions, as you would with numbers:

        DIMENSION V(200,N*2+1)

Or:

        DIMENSION V(200,*)

Remember that you can have lower bounds too if they're appropriate, such
as DIMENSION V(0:N*2).

Adjustable bounds can be anywhere in the list of dimensions bounds for
a dummy array, so DIMENSION V(I:J*2,K-3+L:IX) might well be valid, but
the assumed-size notation "*" can be present only in the upper bound
of the final dimension (otherwise the compiler would have little or no
idea how to calculate the offset into the array), so the ":IX" in this
example could be ":*" instead.

In essence, compilers can safely ignore the upper bound of the last
dimension for dummy arrays (and use them only to calculate how much space
to allocate for local and COMMON arrays), but some use the info to offer
checking for out-of-bounds errors, etc., and the standard permits
correct info to be entered for improved program readability.  It is
wisest to take advantage of these features.
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)