View previous topic :: View next topic |
Author |
Message |
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Thu Sep 08, 2022 10:37 am Post subject: Interface intent differs from subroutine intent |
|
|
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.
Code: | 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
|
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1888
|
Posted: Thu Sep 08, 2022 2:00 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri Sep 09, 2022 6:47 am Post subject: |
|
|
Thanks for the feedback. I will make a note of this issue. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Thu Sep 15, 2022 2:09 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
simon
Joined: 05 Jul 2006 Posts: 268
|
Posted: Thu Sep 15, 2022 5:35 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Fri Sep 16, 2022 6:38 am Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Tue Oct 04, 2022 2:19 pm Post subject: |
|
|
A warning diagnostic has now been added for the next release of FTN95. |
|
Back to top |
|
|
|