FORTRAN 77 does not have the concept of a pointer. However, FORTRAN INTEGERs are widely used in Starlink software as a replacement for pointers when passing the address of a data array from one routine to another. Typically, a FORTRAN program calls a subroutine that returns a value in an INTEGER variable that represents the address of an array, which will usually have been dynamically allocated. The value of this variable (as opposed to its address) is then passed on to another routine where the contents of the array are accessed.
C, of course, does provide pointers - in fact you can hardly avoid using them - and they are distinct from C integers (ints). To take account of this, a macro POINTER is defined to declare C function arguments that the calling FORTRAN program declares as an INTEGER but will actually treat as a pointer. The FORTRAN routine should not process a POINTER variable in any way. The only valid operations it may perform are to copy it, to pass it to a subprogram using the normal parameter passing mechanism, or to pass its value to a subprogram using the %VAL facility in order to access the contents of the array to which it points.
Unfortunately, this scheme of using FORTRAN INTEGERs to hold pointer values only works cleanly if the length of an INTEGER is the same as the length of the C generic pointer type void*. Where this is not the case (on DEC Alphas for instance), some way around the problem has to be found.
On some systems, the linker may have flags to control the size of the address space in which a program runs, and this can provide a simple solution. For example, although addresses on DEC Alphas are normally 64 bits long (the length of a C pointer), it is possible to force programs to use addresses in which only the lowest 32 bits have non-zero values. It then becomes a simple matter to convert C pointers into FORTRAN INTEGERs (which are 32 bits long) because discarding the most significant bits has no effect. The standard Starlink link scripts on DEC Alpha systems supply the necessary command-line flags to produce this behaviour automatically.
However, this simple solution is not always applicable. Apart from the possibility that future 64-bit operating systems (of which there are likely to be an increasing number) may not provide this option of running programs in ``lower memory'', even on those that do the option cannot always be exercised. For example, some software packages make use of ``dynamic loading'' of routines stored in shareable libraries as a way of allowing their capabilities to be extended. This is a very flexible facility, but it means that the loaded routines must execute in the address space of the main program, which means that the writer of the shareable library no longer has any control over the number of bits used in pointers. The only option is then to re-build the main software package with the required linker options. This is at best inconvenient, but in the case of commercial software packages it may be impossible.
There is also an increasing likelihood that programs may need to access data arrays of such size that 32 bits of address space (the usual length of FORTRAN INTEGERs) is insufficient.
CNF and F77 Mixed Language Programming -- FORTRAN and C