forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Interface intent differs from subroutine intent

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu Sep 08, 2022 10:37 am    Post subject: Interface intent differs from subroutine intent Reply with quote

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
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Thu Sep 08, 2022 2:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Sep 09, 2022 6:47 am    Post subject: Reply with quote

Thanks for the feedback. I will make a note of this issue.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Sep 15, 2022 2:09 pm    Post subject: Reply with quote

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
View user's profile Send private message
simon



Joined: 05 Jul 2006
Posts: 268

PostPosted: Thu Sep 15, 2022 5:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Sep 16, 2022 6:38 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Oct 04, 2022 2:19 pm    Post subject: Reply with quote

A warning diagnostic has now been added for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group