Silverfrost Forums

Welcome to our forums

Interface intent differs from subroutine intent

8 Sep 2022 9:37 #29347

The following code compiles in FTN95 without any errors or warnings, while other compilers either issue an error or a warning.

I don't think this is a major problem (in terms of the executable generated by FTN95), but the programmer's error is not detected.

program main
implicit none
real :: a(5) = (/1,2,3,4,5/)
real b
interface
  subroutine f(r,s)
    real, intent(out) :: r(:)    !'IN'  in subroutine
    real, intent(in)  :: s       !'OUT' in subroutine
  end subroutine                 !Should the complier not detect this discrepancy?
end interface
call f(a,b)
print*, 'sum = ', b
end program main

subroutine f(r,s)
real, intent(in) :: r(:)         !'OUT' in interface block
real, intent(out):: s            !'IN'  in interface block
s = sum(r)
end subroutine
8 Sep 2022 1:00 #29348

The inconsistent interface should be caught at run time if /check is specified.

Catching the mismatch at compile time would require an additional pass over the source code, and slow down compilation. For a highly optimising compiler, the additional overhead may be slight, whereas for a fast compiler such as FTN95 the slowdown would be significant.

9 Sep 2022 5:47 #29349

Thanks for the feedback. I will make a note of this issue.

15 Sep 2022 1:09 #29352

This is a good example of why Fortran INTERFACE is a totally flawed approach. There should have been a requirement in the Fortran standard that INTERFACE definitions shoul be generated and managed in the .obj file and NOT duplicated in Fortran code.

15 Sep 2022 4:35 #29353

There may well be scope for improving on interface design. However, I have found them useful when passing a procedure as an argument to a subroutine when the procedure cannot be included in a Use statement because doing so would create circular dependencies. So there are cases - perhaps only because of my poor program design! - in which it would be impossible to generate and manage the interface in the .obj file.

16 Sep 2022 5:38 #29355

Simon,

Sorry, my comment was not as a solution to your problem, but my venting at the poor design of Fortran's INTERFACE.

If you define an interface, you are duplicating Fortran code, which becomes wrong if the original procedure is modified. Duplicating the code is a very error-prone approach, as seen in Ken's example.

An alternative could be to have the interface generated by the Fortran compiler and then used where required. This would be a very complex requirement, as an interface for a 'library' of routines would be difficult to manage. This would require a multi-pass compile to first generate the interface for all routines in all .obj/.lib files, possibly defined in a class of .int files that need to first be updated before compiler checking.

A second best would be to check all routine calls in 'slink', needing both the interface definition stored in the .obj files and all routine calls also documented in the .obj files. I think the Intel compiler provides some functionality for this. Most compilers can check the interface definitions, if all routines are in the same .f90 file, although FTN95 did not appear to in this example.

4 Oct 2022 1:19 #29407

A warning diagnostic has now been added for the next release of FTN95.

Please login to reply.