More on Implicit Interfaces

Implicit interfaces are the old, F77 way of communication. Separate procedures are desired to be as independent as possible from one another (so that they can be written, compiled and maintained independently); in particular, a procedure is totally ignorant of how a different procedure looks like.

Special problems arise when procedures call each other; the caller has very limited knowledge on the called procedure; it passes a list of actual argument addresses to the called procedure; the called procedure retrieves this addresses in order, and assumes they are the addresses of the dummy arguments.

The disadvantage of this approach is that the compiler is able to perform only limited consistency checks. In F77, it is easy to make mistakes undetectable by the compiler when working with argument lists.

Consider, for example, the following F77 subroutine

      subroutine BubbleSort(iv,n,how)
      integer n, how, iv(*)
      integer i, j, tmp, iperm
      iperm = 0
      do i=1,n
        do j=i,n
	  if ( how.eq.-1 .and. iv(i).lt.iv(j)  .or.
     &         how.eq.1  .and. iv(i).gt.iv(j) ) then
	    tmp   = iv(i); iv(i) = iv(j); iv(j) = tmp
	    iperm = iperm + 1
	  end if
        end do
      end do
      how = iperm
      end

The subroutine receives a vector of integers, iv of dimension n (here the star means assumed size, that is the routine receives the address of the first aelement and is able to handle the whole vector from here). The routine returns the vector iv with elements sorted in increasing order (if how=+1), or in decreasing order (if how=-1); upon return the variable how will contain the number of swaps performed by the bubble algorithm.

The main program can be

      program impint
      integer n
      parameter (n=4)
      integer iv(n), iw, how
      data iv /3,1,4,2/
      how = -1
      call BubbleSort(iv, n, how)
      print *, 'sorted decreasingly: ',(iv(i),i=1,n),'  how:', how
      end

and produces the output

Sorted Decreasingly:     4   3   2   1  How:  3

Now, if we mistype

      hoe = -1
      call sort(iv, n, hoe)

the variable hoe will be considered a real variable; the bytes starting at that memory address will be considered as representing an integer (-1082130432) by the subroutine; since it is not or , the output is 3 1 4 2. Note that, since the main program knows nothing about the subroutine sort, the compiler cannot detect the inconsistency of using a real actual argument hoe when the third dummy argument how is of type integer.

Suppose we call

      call sort(iv, n, -1)

This call is fine for input purposes, the third argument being a constant of type integer; the problem is that the third argument (how) is intended to return the number of swaps, and is written inside the procedure; this produces a segmentation fault (it is anyway clear that we cannot write the constant ). Again, the compiler cannot help us because of its limited knowledge of the function.

The call

      call sort(iv, n)

is also fine with the compiler; obviously, the dummy argument how will not be initialized (in fact it takes a garbage-value). Similarly, we can include extra arguments without bothering the compiler

      call sort(iv, n, how, extra)

(but we can trick ourselves if we want to read the value of extra upon return).

Also, if iw is an integer scalar, the call

      call sort(iw, n, how)

is permitted by the compiler; since F77 assumes that the entries of iv are stored sequentially into memory, the subroutine will "work" with the memory locations following those that contain iw; if we are lucky we get a segmentation error; if not, other data can be messed up - without any warning - and we get meaningless results.