Forcing explicit subroutine interface compliance?

[David_Hittner]

Is there some way to tell the compiler that all called subroutines *must* have their interfaces declared explicitly, either through a USE statment or an INTERFACE statement, to ensure API compliance at compile time (similar to ANSI C Prototypes)?

Also, if a command line switch to enable explicit interface checking exists, is there also a CDEC$ way of forcing it?

[Steven_L_Intel1]

No, though I've seen this request before.  But we do have a feature called Generated Interface Checking that will compare calls against "external" Fortran procedures in your application.  It won't help for C calls.

We already have a feature request on file for this, DPD200233537.  It is an intriguing idea.

[IanH]

Me too!

For example, I think g95 has a warning for a procedure with an implicit interface being referenced.

With long build times it can be rather annoying to get all the way to the link stage just to have the build bomb out with a error because you forgot a USE somewhere in one of the first source files compiled.

[John_Campbell]

I have never liked the INTERFACE structure as, while it duplicates the declarations in the called routine, there is no guarantee that these have not been changed in the actual routine.
If you change a routine that requires an INTERFACE, then you must then search for all uses of this routine and update both the call and the INTERFACE block.
While the compiler can readily check for consistency between the interface block and the call, it would be good if the compiler could selectively check the INTERFACE for consistency with the actual routine.
It is a shame that there was never a convention to count the number of arguments in a subroutine call and check that at run time, after accounting for the case of optional arguments.
These can be very difficult bugs that can creep in when you are rushing to get some patch to work and don't check the consequences elsewhere in the project or more typically where the code is shared between projects. The problem then arises much later when that quick patch is long forgotten.

John

[Steven_L_Intel1]

I agree with John, and have said several times in my "Doctor Fortran" posts, that if you have written an interface block for a Fortran routine (not counting generic interfaces), you're doing it wrong.  But such an option would warn if a module was not used when it should be.  As suggested earlier, failure to do so is not detected until link time, which may be way down the road in the build process/

[FortranFan]

As I mentioned in one of my earlier posts (http://software.intel.com/en-us/forums/topic/391387), I can't wait for the Fortran 2008 SUBMODULEs feature in Intel Fortran to start gaining a better handle on interface checking in some of my larger programs.

It seems to me that folks who develop Fortran standards missed a trick in not including the aspect of subroutines and functions "self-referencing" the interfaces - perhaps a lot less time might have been lost by programmers in chasing down bugs if such a capability were present and was getting used.

[Steven_L_Intel1]

I know that the "interface to self" idea was debated seriously in the standards committee, but I wasn't present and don't know why they chose to not go forward with it.

[jimdempseyatthecove]

You could perform your own name mangle, and add that as a suffix to the subroutine name, then in your USE/INTERFACE block have the external name without the name mangled suffix, and with an alias to the correct mangled name. An alternate would be to add a suffix that is a version number or some such way to disambiguate between arguments.

Intel could have the compiler generate name mangled entries (as an option).

Jim Dempsey

[Steven_L_Intel1]

Fortran 2015 will have:

IMPLICIT NONE (EXTERNAL)

that forces explicit interfaces. 

[andrew_4619]

ianh wrote:

Me too!

For example, I think g95 has a warning for a procedure with an implicit interface being referenced.

With long build times it can be rather annoying to get all the way to the link stage just to have the build bomb out with a error because you forgot a USE somewhere in one of the first source files compiled.

Me too too! This happen to me all the time.

[FortranFan]

Steve Lionel (Intel) wrote:

Fortran 2015 will have:

IMPLICIT NONE (EXTERNAL)

that forces explicit interfaces. 

Steve,

Thanks.

By the way, see app4619's post following yours.  Similar to how Intel implemented all of Fortran 2015 features of enhanced interoperability with C (kudos for Intel for this), is it possible to quickly get the Fortran 2015 feature of "IMPLICIT NONE (implicit-none-spec-list)" implemented too? You may know gfortran has had this feature for close to a year now since GCC 5.0. This can help Intel Fortran users adopt the "standard" approach sooner.  

[Steven_L_Intel1]

I have suggested to the developers that this would be a nice thing to do sooner than later. Their plate is pretty full, but we'll see.

[jimdempseyatthecove]

Steve,

Can you address "interface enforcing" as it may apply to statement functions? I can see this as being problematic.

Jim Dempsey

[Steven_L_Intel1]

Statement functions? Not involved in this at all. These are not external procedures.

[jimdempseyatthecove]

>>Not involved in this at all. These are not external procedures.

(to be silly) then you can argue that CONTAINED procedures should not have interface enforcement - eh!

Jim Dempsey

[Steven_L_Intel1]

But contained routines don't have implicit interfaces, so they too are unaffected.

The new feature disallows calling external procedures that have implicit interfaces.

[IanH]

Steve Lionel (Intel) wrote:

But contained routines don't have implicit interfaces, so they too are unaffected.

The new feature disallows calling external procedures that have implicit interfaces.

I think that last bit should be "disallows calling external procedures that have not explicitly been declared to have the EXTERNAL attribute".  Calling something EXTERNAL with an implicit interface would still be permitted.

(IMPLICIT NONE(EXPLICIT) or whatever could have been handy too.)

[FortranFan]

jimdempseyatthecove wrote:

>>Not involved in this at all. These are not external procedures.

(to be silly) then you can argue that CONTAINED procedures should not have interface enforcement - eh!

Jim Dempsey

Perhaps Jim can elaborate on what he means by "interface enforcing" and in what context i.e., is it within the context of Fortran 2015 standard or with Intel Fortran compiler, etc.

Fortran 2015 standard (and 2008 and 2003) has marked "statement functions" as obsolescent: the wording is "Statement functions are subject to a number of nonintuitive restrictions and are a potential source of error because their syntax is easily confused with that of an assignment statement.  The internal function is a more generalized form of the statement function and completely supersedes it."

With the internal function, the interface is explicit and therefore, there is no question within the context of the standard for any means for "interface enforcing" that can arise with external procedures.

[andrew_4619]

ianh wrote:

(IMPLICIT NONE(EXPLICIT) or whatever could have been handy too.)

That would be my EXPLICIT ALL suggestion from a couple of years back,  none of that inverted double negative juggling whilst tightrope walking logic  :-) or maybe I have just got too confused and should go for a beer.....

[jimdempseyatthecove]

>>Perhaps Jim can elaborate on what he means by "interface enforcing"

implicit none
! integer :: i ! not defined
integer(4) :: i4, i4Too
integer(8) :: i8, i8Too
StatementFunction(i) = i*i ! ?? is this valid as type of i not defined
SecondStatementFunction(i4) = i4*i4 ! ?? does this imply/require integer(4)
...
i4Too = 1234
i4 = SecondStatementFunction(i4Too) ! should be valid as types match
i8Too = 5678
i8 = SecondStatementFunction(i8Too) ! ?? should be invalid as types do not match

*** Note, I am not stating what is or is not valid. Just clarifying for FortranFan
 

Jim Dempsey

[FortranFan]

jimdempseyatthecove wrote:

>>Perhaps Jim can elaborate on what he means by "interface enforcing"

implicit none
! integer :: i ! not defined
integer(4) :: i4, i4Too
integer(8) :: i8, i8Too
StatementFunction(i) = i*i ! ?? is this valid as type of i not defined
SecondStatementFunction(i4) = i4*i4 ! ?? does this imply/require integer(4)
...
i4Too = 1234
i4 = SecondStatementFunction(i4Too) ! should be valid as types match
i8Too = 5678
i8 = SecondStatementFunction(i8Too) ! ?? should be invalid as types do not match

*** Note, I am not stating what is or is not valid. Just clarifying for FortranFan
 

Jim Dempsey

Thanks, Jim, but again, I'm not sure if you're suggesting Intel Fortran compiler to provide some enforcement for statement functions.  For Fortran standard has clearly made its intent clear by marking statement functions as obsolescent.  So all those codes out there that still might have statement functions can either with live with the situation that they have tolerated all these years (no interface checking and no enforcement) or move on to something different, perhaps contained procedures as recommended by the standard.  In your experience, how large you reckon is the FORTRAN code base that still makes use of statement functions?  I personally have only come across one program (huge, commercial simulation code) that made use of statement functions and that was many years ago; surprisingly, the vendor had on their own decided to do away with statement functions and replaced them with another approach that obviated the need.