Interface checking with procedure pointers

[OP1]

The code shown below does not trigger a compile/link time error; it does not trigger an error at runtime either. I am puzzled by several things here:

1. As shown, the code runs but outputs the value '2' - which seems to come out of nowhere.
2. If you uncomment line 19 and comment line 20, the compiler will detect the improper argument list (error #6633).
3. Shouldn't an error be triggered on line 17, due to the mismatch in interfaces?
4. If a third argument (say, Z) is added to the definition of F (and the rest of the code stays as is), then I get an expected access violation error.

Does this mean that ensuring matching interfaces when using procedure pointers is the sole responsibility of the developer? But if yes, then why does (2) above leads to an error (as it should)?

FUNCTION F(X,Y)
IMPLICIT NONE
INTEGER F,X,Y
F = X+Y
END FUNCTION F


PROGRAM MAIN
IMPLICIT NONE
ABSTRACT INTERFACE
    FUNCTION G(X)
    IMPLICIT NONE
    INTEGER G,X
    END FUNCTION G
END INTERFACE
PROCEDURE(G),POINTER :: FUN => NULL()
PROCEDURE(G) :: F
FUN => F
!WRITE(*,*) FUN('a')
WRITE(*,*) FUN(1)
END PROGRAM MAIN

[Steven_L_Intel1]

Generated interface checking currently gets activated only when you reference a procedure that has an implicit interface. Yes, it is your responsibility to ensure that the interface matches.  Your item 2 occurs because the function reference conflicts with the explicit interface that is visible.

It would be an interesting extension to also check explicit interfaces against separate procedures, but the primary purpose of the feature was to help find errors in old, Fortran 77-style code without explicit interfaces. 

[OP1]

ok - thanks Steve, I got it: the only check performed for the call on line 20 is the consistency with the abstract interface explicitly defined above; not with the external function.

Yes it would be nice to have a check against the interface of separate procedures - it seems all the information is readily available.

[Steven_L_Intel1]

A possible problem with extending this is that I've seen quite a few programs, including some I wrote myself, where the explicit interface is deliberately different from the external procedure.

I will file a feature request for this.