[J3] Is this standard-conforming?

Steidel, Jon L jon.l.steidel at intel.com
Thu Jul 26 15:54:14 EDT 2018


I'm not sure I see a difference between and IMPORT of a type or a named constant in a function interface body and the USE association of the type or the named constant.  

Consider

module mod

  character(len=5), parameter :: d_name="d_foo"

end module

program main
   implicit none

  character(len=5), parameter :: c_name="c_foo"

  interface
    subroutine foo() bind(C,name=c_name)
      use mod, c_name => d_name
  !    import c_name
    end subroutine
  end interface

  call foo()

end  program

subroutine foo_c () bind (C, name="c_foo")
   print *, "hello"
end

subroutine foo() bind (C, name="d_foo")
   print *, "goodbye"
end

Two compilers I have tried accept this and print "goodbye".  

-jon


-----Original Message-----
From: J3 [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Bill Long via J3
Sent: Thursday, July 26, 2018 2:38 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Bill Long <longb at cray.com>
Subject: Re: [J3] Is this standard-conforming?

Thanks, Dan, for looking this up. At least by m218 the /INTERP subgroup should be back in business.  

I should note that there IS a way around this for a function type. Instead of 

    type(ugg) function foo()

you can write

    function foo()  result(res)
      import ugg
      type(ugg) :: res

In the second case there is no room for ambiguity because the use of ugg is in the specification part of the function which is clearly covered by the import statement.  However, the standard still permits the first version, hence the need for compilers to implement a limited look-ahead capability. 


Cheers,
Bill


> On Jul 26, 2018, at 1:12 PM, Dan Nagle via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Hi,
> 
>> On Jul 26, 2018, at 10:23 , Bill Long via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> Similar to your case, the import of ugg  from the host occurs on the statement after the one where ugg is used.  In the case of a type definition like this there is no practical alternative, so compilers have been taught to ‘look ahead’ for a type definition.   I suspect we intended to allow the case you described, but the vendors did not anticipate needing to do a look-ahead for anything other that the function type.   If Malcolm disagrees about the intent, I’m ok with that.   I think it boils down to whether the FUNCTION statement itself is part of the scoping unit of the function. 
>> 
> 
> And indeed, this is the oldest interpretation request in the file.
> The issue has been argued, and the argument accepted, both ways.
> 
> --
> 
> Cheers!
> Dan Nagle
> 
> 

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425




More information about the J3 mailing list