A gap in interface checking for procedures? Can it be filled?

[FortranFan]

This is based on a discussion at comp.lang.fortran: https://groups.google.com/forum/#!topic/comp.lang.fortran/nzq3Sad_zQE

The following code generates no compiler warnings with /warn:interfaces or /warn:all:

MODULE m

   !..
   IMPLICIT NONE

   !..
   PRIVATE

   !..
   PUBLIC :: s1_intent_in

CONTAINS

   SUBROUTINE s1_intent_in(ia)
      INTEGER,INTENT(IN) :: ia
      CALL s2_intent_in(ia)
      RETURN
   END SUBROUTINE s1_intent_in

   SUBROUTINE s2_intent_in(ia)
   
      INTEGER :: ia  ! Missing INTENT attribute
      
      ia = 2         ! Dummy argument should be subject to limitations of actual argument
                     ! i.e., it cannot be redefined; shouldn't the compiler be able to catch
                     ! this and issue some warning?
                      
   END SUBROUTINE s2_intent_in

END MODULE m

Intel Fortran documentation summarizes the standard nicely: "If no INTENT attribute is specified for a dummy argument, its use is subject to the limitations of the associated actual argument."

This appears to be a gap in interface checking - can it be filled?

Thanks,

[jimdempseyatthecove]

Although for this case the compiler has the information to issue a warning the "is subject to the limitations" is a declaration to the programmer as to what they ought or ought not do with the argument.

Your s1_intent_in subroutine could very well have called FooBarExternalUnknown(ia) where the compiler has no foreknowledge of what that subroutine does with ia.

Steve, will likely have the inside story as to if in this case a warning or error should be emitted.

Jim Dempsey

[FortranFan]

jimdempseyatthecove wrote:

Although for this case the compiler has the information to issue a warning the "is subject to the limitations" is a declaration to the programmer as to what they ought or ought not do with the argument.

Your s1_intent_in subroutine could very well have called FooBarExternalUnknown(ia) where the compiler has no foreknowledge of what that subroutine does with ia.

Steve, will likely have the inside story as to if in this case a warning or error should be emitted.

Jim Dempsey

Jim, yes I did intend the comments in the original post to apply to situations where explicit interfaces are available such as "contained" procedures in the example.

Thanks, 

[IanH]

That's not really a problem with interface checking (is this procedure invocation consistent with the procedure interface) - it is more a question of whether the procedure body is respecting the limitations of the effective argument (and perhaps poor programming style in not being explicit about the requirements on the effective argument by not having INTENT([IN] OUT) on the dummy argument in s2_intent_in.  Consider the case when the actual argument in the call to s2_intent_in is replaced with a constant.  This is the same underlying problem (the effective argument is not definable) but intent doesn't come into it.

But that said, note:

>ifort /check:all /warn:all /standard-semantics /Qdiag-enable:sc "2015-02-02 intent.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.148 Build 20141023
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.
ifort: command line remark #10010: option '/Qdiag-enable:sc' is deprecated and will be removed in a future release, which frankly is a bit of a shame. See '/help deprecated'
ifort: command line remark #10399: For additional information, please visit 'https://software.intel.com/en-us/static-analysis-deprecation'

ifort: remark #10336: Static analysis complete; results available in ".\r005sc\r005sc.inspxe"

>inspxe-cl -report problems
P1: Error: IN arg modified: New
1
Other
2015-02-02 intent.f90(16): error #12013: dummy argument "IA" declared as INTENT(IN) shouldn't be modified, but it is modified in "S2_INTENT_IN" at (file:2015-02-02 intent.f90 line:24)
 P1.1: Error: IN arg modified: New
2015-02-02 intent.f90(16): error #12013: dummy argument "IA" declared as INTENT(IN) shouldn't be modified, but it is modified in "S2_INTENT_IN" at (file:2015-02-02 intent.f90 line:24)
  X1: Definition: U:\projects\FortranMisc\FortranMisc\2015-02-02 intent.f90(16): Function S1_INTENT_IN
  X2: Bad memory write: U:\projects\FortranMisc\FortranMisc\2015-02-02 intent.f90(24): Function S2_INTENT_IN

[Steven_L_Intel1]

Note that omitting INTENT is not the same as INTENT(INOUT). You can see this by giving the argument INTENT(INOUT) in s2 and you'll see:

t.f90(16): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.   [IA]
      CALL s2_intent_in(ia)
------------------------^

What you're asking is for the compiler to supply its own INTENT for S2 based on what it thinks you did with the dummy argument. I've thought about this for external procedures related to generated interfaces, but concluded that it had too many possibilities for false alarms. I doubt we could justify this when an explicit interface is provided. Even the error you get now with INTENT(INOUT) is possibly erroneous, since the routine might have some logic that avoids redefinition of the argument.

What I could get behind is an option that requires you to specify INTENT on every dummy argument (or at least warns you when you don't.)

[FortranFan]

Steve Lionel (Intel) wrote:

..

What I could get behind is an option that requires you to specify INTENT on every dummy argument (or at least warns you when you don't.)

Steve,

I think that will be a very useful option (/warn:intent ?!) to have.  It'll be great if you can take it up with the developers.

Thanks much,

[Steven_L_Intel1]

Turns out this is already on our "feature request" list as DPD200233540.

[FortranFan]

Excellent, thanks.

[andrew_4619]

Steve Lionel (Intel) wrote:

Turns out this is already on our "feature request" list as DPD200233540.

I am liking that one too :-)

[IanH]

What's the thinking with respect to this "you forgot INTENT!" warning and VALUE arguments?

[Steven_L_Intel1]

I could see it being reasonable to not issue the warning for VALUE arguments, though I think INTENT is always a good idea as it allows the compiler to check what you do with the argument inside the routine.

[IanH]

Perhaps using VALUE on "native" Fortran procedures (not BIND(C)) is an obscure edge case, but as you cannot specify INTENT(xxOUT) and VALUE together for an argument, and specifying INTENT(IN) and VALUE defeats the conceptual point of VALUE for native procedures, I think that's one exception you'd have to let through.

In terms of the original discussion about INTENT(IN) things being inadvertently modified I don't think it matters, because any modification inside the lower level procedure is done to the copy.

The companion warning that's required is a call to a procedure with an implicit interface.  That's something I'd really like to see - in part because currently a speling mistake in a procedure name gets picked up at link time, which can be rather annoying when building large projects.

[Steven_L_Intel1]

I had not remembered that bit about VALUE. So I agree with you there.

[andrew_4619]

IanH wrote:
The companion warning that's required is a call to a procedure with an implicit interface.  That's something I'd really like to see - in part because currently a spelling mistake in a procedure name gets picked up at link time, which can be rather annoying when building large projects

Yes I recall discussing it this one in another thread, it gets me on a regular basis and is a real time waster. The three cases are:

1) subroutine name misspelling

2) subroutine from a module is used and is not added to the "USE, ONLY:" or USE not added in the calling routine.

3)  subroutine from a module is used but I have foolishly not made the subroutine PUBLIC in a module where PRIVATE is the default..

In all of these cases the compiler assumes it is an external subroutine, does a full build and fails on the link stage. A compiler warning would be very nice. A language feature (EXPLICIT ALL) would be even nicer but that is another story.....

[Steven_L_Intel1]

The language feature is coming in F2015 - the spelling is "IMPLICIT NONE (EXTERNAL)" You can also use TYPE (and EXTERNAL if you want) in this syntax to be the same as IMPLICIT NONE today.

[FortranFan]

Steve Lionel (Intel) wrote:

The language feature is coming in F2015 - the spelling is "IMPLICIT NONE (EXTERNAL)" You can also use TYPE (and EXTERNAL if you want) in this syntax to be the same as IMPLICIT NONE today.

"IMPLICIT NONE (EXTERNAL)" - utterly horrible.

[andrew_4619]

@FF Yes perhaps not the most elegant but I can live with that....

@Steve, I didn't get the TYPE EXTERNAL syntax/usage and I read a J3 document and I wasn't much wiser. could you give a two liner code snip showing usage?

I guess 2015 will get published in 2016 some time? Given 2003 is done (other than I guess a few bug fixes and further optimisations perhaps) and F2008 is well under way, I guess some of the 2015 features should arrive quite quickly given it is a 'minor' changes standard?  

[Steven_L_Intel1]

Examples:

IMPLICIT NONE (EXTERNAL) ! No implicit external interfaces
IMPLICIT NONE (TYPE) ! Same as IMPLICIT NONE
IMPLICIT NONE (EXTERNAL, TYPE) ! No implicit type or interfaces

Don't look for publication before late 2017. The C interoperbility features from F2015 are showing up in compilers now, the parallel features are more problematic and some are still in flux.