FORTRAN 77 array sizes are determined at the time of compilation, 
 the 'top declaration' of the array allocates a chunk of memory, 
 and the size of that memory chunk can't be changed during runtime. 

 Sometimes we don't know beforehand the array size, because the size 
 of the input data is unpredictable or inconstant.

 There are some methods to solve this problem in the framework of 
 FORTRAN 77, two of them standard conforming and somewhat limited, 
 the others are non-standard. 

 Fortran 90 support of automatic and allocateable arrays solved 
 this problem in a much better and portable way. 

 Standard-conforming methods
 The idea behind these methods is simple: declare in the calling 
 procedure an array larger than the maximum expected size and 
 use only part of it in the called procedure. 

 There are two options now:

    1) Pass the 'physical' and 'logical' array dimensions, 
       ('physical' means here the original dimensions, and 
        'logical' are the reduced dimensions). 
       Declare the array with the 'physical' dimensions and 
       Use the dimensional variables to explicitly limit all 
       LOOP CONTROL VARIABLEs to the 'logical' dimensions.

    2) Re-define the array in the called subroutine to have
       the required size. Be careful, after once writing to a 
       re-defined multi-dimensional array, all the procedures 
       referencing it must re-define it to the same dimensions 
       (or compute manually all indices).

 By the way, re-definition of the dimensions of an array passed 
 to a procedure, is valid according to the FORTRAN 77 standard. 

 From the point of view of memory utilization (minimization of 
 memory paging, at least for multi-dimensional arrays) it is 
 preferred to redefine the array dimensions. In this method we 
 use the original array as a kind of memory pool only.

 Both options use the syntax of adjustable arrays.

 Example of the physical/logical method

      program phylog
      integer     nphys, nlog, i
      parameter   (nphys = 100)
      real        a(nphys)
      do i = 1, nphys
        a(i) = i
      write(*,*) 'enter array size: '
      read(*,*) nlog
      if (nlog .gt. nphys) stop 'too large passed array '
      call sub(a, nphys, nlog)

      subroutine sub(a, nphys, nlog)
      integer    nphys, nlog, i
      real       a(nphys)
      do i = 1, nlog
        write (*,*) i, a(i)

 Example of the re-definition method

      program recnfg
      integer     nphys, nlog, i
      parameter   (nphys = 100)
      real        a(nphys)
      do i = 1, nphys
        a(i) = i
      write(*,*) 'enter array size: '
      read(*,*) nlog
      if (nlog .gt. nphys) stop 'too large passed array '
      call sub(a, nlog)

      subroutine sub(a, n)
      integer    n, i
      real       a(n)
      do i = 1, n
        write (*,*) i, a(i)

 A more fancy example for the redefinition technique: 

      program adjarr
      integer	i, j, m, n, a(9,9)
      do i=1,9
        do j=1,9
          a(i,j) = 10*i + j
      write(*,*) ' '
      write(*,*) '  we have an integer array of size 9x9 '
      write(*,*) '  array(i,j) = (10 * i) + j            '
      write(*,*) ' '
      write(*,*) '  we will pass it to a subroutine with '
      write(*,*) '  the adjustable array mechanism.      '
      write(*,*) '  the array dimensions will be         '
      write(*,*) '  re-defined to  m x n                 '
      write(*,*) ' '
      write(*,*) '  please supply m,n the new            '
      write(*,*) '  dimensions in the range [1-9]        '
      write(*,*) '  '
      write(*,*) 'enter m: '
      read(*,*) m
      write(*,*) 'enter n: '
      read(*,*) n
      call sub(m,n,a)

      subroutine sub(m,n,a)
      integer    m, n, a(m,n)
      write(*,*) '  the re-defined array is: '
      write(*,'(1x,i4)') a 

 The variable format used in the last WRITE statement is non-standard.

 Non-standard methods
 All these solutions are based on the ability of most operating systems 
 to allocate a contiguous area of memory to a running program upon request.  
 Operating systems supply non-standard (from FORTRAN point of view) 
 'system calls' that a program can utilize to request a memory chunk 
 while running.

 A better solution is to use the memory allocating functions of C, 
 of course they are implemented with those system calls, but the C 
 interface is standard (C standard).

 The following examples will work when certain requirements are met, 
 we will try to make them explicit as possible.

 The classical 'non-contiguous array' trick 
 The main-program allocates the memory for the 'client procedure', 
 where a few simple manipulation are performed on the newly created
 array, just to prove the method works.  Passing the array element 
 A(OFFSET) to a subroutine, make it easier to access the 'array extension'. 

 We declare an array A with one element, the 'mem' routine allocates
 memory for 100 elements the size of each is 4 bytes. 'mem' returns 
 an 'array index' OFFSET, computed with 'pointer arithmetic', that 
 integer is the 'start index' of the 'array extension'.  The routine 
 'unmem', of course, deallocates the new memory area.

 Here we probably assume a call-by-reference argument passing mechanism, 
 and our INTEGERs are 4 bytes long.  Another assumption is that the 
 Fortran compiler doesn't append an underscore to external names
 (see the chapter on Fortran/C interfacing).

      program dynarr
      integer*4		a(1), offset
      call mem(a, 100, 4, offset)
      call sub(a(offset))
      call unmem(a, 100, 4, offset)

      subroutine sub(a)
      integer		a(100), i
      do i = 1, 100
       a(i) = i
      write(*,*) a

#include <stdlib.h>
#include <stdio.h>

void mem(int *a, int *m, int *n, int *b)
    int     *new;

    new = (int *)calloc(*m, *n);

    if (new == NULL)
        printf("\n not enough memory \n");
        *b = (int)(new - a) + 1;

void unmem(int *a, int *m, int *n, int *b)
    free(a + *b - 1);

 Another example, a 5x5 two-dimensional INTEGER*2 array is allocated 
 and initialized in a C routine:

      program test
      integer		m, n, offset
      Integer*2		matrix(1)
      call mem(matrix, offset)
      m = 5
      n = 5
      call sub(m, n, matrix(offset))

 A FORTRAN routine (just for testing):

      subroutine sub(m, n, matrix)
      integer		m,n, i
      integer*2		matrix(m,n)
      write (*,*)
      write (*,*) ' In Fortran: '
      write (*,*)
      write (*,'(1X,5I11)') ((matrix(i,j), j=1,5), i=1,5)

 The C routine can't modify the value of the pointer to "matrix", 
 so we use the non-contiguous array technique, and compute the 
 "offset" between a one-element array declared in the Fortran 
 code and the new allocated array.

 We use the allocated array in sub-procedures of the procedure 
 that called the C routine, by passing to them "matrix(offset)" 
 which is a "pointer" to the new array computed by f77.

 The whole method can be easily made flexible, and you can have 
 different size for the array on each run (with the adjustable 
 array syntax).

#include <stdio.h>
#include <stdlib.h>

mem(short **matrix, long *offset)
	long	m, i, j;
	short	*ptr, **aux;

	ptr = (short *) malloc(25 * sizeof(short));
	*offset = (long)(ptr - (short *)matrix + 1);

	aux = (short **) malloc(5 * sizeof(short *));
	for(m = 0 ; m < 5 ; m++)
    		*(aux + m) = (short *)(ptr + (5 * m));

	printf("\n In the C routine: \n");

        for(i = 0 ; i < 5 ; i++)
                for(j = 0 ; j < 5 ; j++)
                        aux[i][j] = (i+1) * 10 + (j+1);
                        printf("%11d", aux[i][j]);



 Note that the C routine allocate the storage actually used in the 
 Fortran code in the first "malloc", it computes the offset between 
 the one-element Fortran array and the new array with a bit of 
 pointer arithmetic and passes it back to the Fortran code.

 The output looks like this:

 In the C routine: 

         11         12         13         14         15
         21         22         23         24         25
         31         32         33         34         35
         41         42         43         44         45
         51         52         53         54         55

 In Fortran: 

         11         21         31         41         51
         12         22         32         42         52
         13         23         33         43         53
         14         24         34         44         54
         15         25         35         45         55

 Note that printing "row by row" produces
 transposed results!

 Some remarks on the C routines used above
 On most UNIX machines, you will have to add a trailing underscore to 
 the routine names (mem_, unmem_). See the chapter on FORTRAN/C 
 interface, or just add the underscore if the compiler/linker complains.

 Old C compilers (non-ANSI), declare the dummy (formal) arguments types
 not inside the argument list, but in a separate line just below it.

 Explicitly controlling the parameter-passing-mechanisms 
 Here we probably assume a call-by-reference argument passing mechanism, 

   1) The existence of language extensions that control 
      the mechanism of parameter-passing (In this example 
      DEC fortran extensions are assumed).

   2) The pointer returned by 'malloc' can be stored
      in an INTEGER variable and then passed intact
      to a FORTRAN procedure (valid in most machines?).

      program dynarr
      integer		m, n, ptr
      write(*,*) ' enter two integers: '
      read(*,*) m, n
      ptr = malloc(%val(m*n))
      if (ptr .eq. 0) stop 'not enough memory '
      call sub(%val(ptr), m, n)

      subroutine sub(arr, m, n)
      integer		m, n, arr(m,n), i, j
      do j = 1, n
        do i = 1, m
          arr(i,j) = 10*i + j
      write(*, '(1x,i5)') arr

 Many compilers support Cray pointers, these beasts may be used
 for memory allocation, but be careful, using Cray pointers for
 in computation may cause erroneous results (when automatic
 compiler optimization is turned on - the default).

Return to contents page