J3/05-127 Date: 12 January 2005 To: J3 From: Aleksandar Donev Subject: Implicit interfaces and conflicting references NUMBER: TITLE: Implicit interfaces and conflicting references KEYWORDS: implicit interface, procedure pointer, dummy procedure, procedure reference DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Is the following program legal: _________________________ module test_mod contains subroutine reference(proc,choice) ! Proc has implicit interface external :: proc ! Or ! procedure(), pointer :: proc logical :: choice if(choice) then call proc(1.0) ! Call with real argument else call proc(1) ! Call with integer argument end if end subroutine subroutine proc_real(x) real :: x end subroutine subroutine proc_integer(x) integer :: x end subroutine end module program test use test_mod call reference(proc_real,.true.) call reference(proc_integer,.false.) end program _________________________ 12.3.2.5 says: "The type...of dummy arguments of a procedure referenced from a scoping unit where the interface of the procedure is implicit shall be such that the actual arguments are consistent with the characteristics of the dummy arguments." We define a procedure reference in 2.5.6 as the "appearance of procedure designator, ... in a context requiring execution at that point." Are both calls to proc above references, at compile time? If both calls to proc are references than they both need to be consistent with the interface of the actual argument associated with the dummy procedure. This is not possible and the program would be illegal. However, if only the call executed counts as a reference, than the program is legal. The same question applies to both dummy procedures and procedure pointers with implicit interfaces. ANSWER: No, the program is not legal---both calls to proc in the module subroutine reference are references of the dummy procedure proc and thus must both be consistent with the interface of the actual. EDITS: In 2.5.6, replace "in a context requiring execution at that point" with "in a context which may require execution of the procedure", or some other wording. The intent is to exclude appearances of the procedure identifier in contexts which are not really procedure invocations. SUBMITTED BY: Aleksandar Donev HISTORY: 05-127 m171 Submitted