Given that the kind type parameters are different in
> INTERFACE FOOBAR
> FUNCTION C_LOC_Function_sp (X) RESULT (c_pointer)
> INTEGER(i_sp), EXTERNAL :: X
> INTEGER (KIND=C_ADDRESS) :: c_pointer
> END FUNCTION
> FUNCTION C_LOC_Function_Dp (X) RESULT (c_pointer)
> INTEGER(i_dp), EXTERNAL :: X
> INTEGER (KIND=C_ADDRESS) :: c_pointer
> END FUNCTION
> END INTERFACE
I would expect this to be OK. [277:24-31] in the F95 standard (97-007r2)
says
(2) at least one of them shall have both
(a) A nonoptional dummy argument that corresponds by position ...
to a dummy argument ... present [in the other] ... with a
different kind type parameter ... and
(b) [same thing but by name].
The requirement doesn't say "dummy data object," so I assume "dummy
function with a different kind for the result" meets the requirement.
I don't have the corrigenda handy, so I don't know whether this passage
has been superceded or interpreted differently from how I see it today.
> Van Snyder wrote:
>
> > Presumably there's more to it than this -- definition of kind type
> > parameters in particular.
> > This could well be a portability problem, not a language problem.
> No, sorry I forgot to say that, the two kinds are different.
>
> i_sp= 4
> i_dp= 8
>
> The problem is with the EXTERNAL attribute. I would have wanted the
> following interface, which does not distinguish between functions and
> subroutines:
>
> FUNCTION C_LOC_Subroutine (X) RESULT (c_pointer)
> EXTERNAL :: X
> INTEGER (KIND=C_ADDRESS) :: c_pointer
> END FUNCTION
>
> But if I try the following:
>
> write(*,*) C_LOC_Subroutine(f) ! Line 35
> write(*,*) C_LOC_Subroutine(g) ! Line 36
>
> where f is real and g is integer:
>
> real function f(x)
> real :: x
> f=x
> end function
> integer function g(x)
> real :: x
> g=x
> end function
>
> I get from NAG (with a flag to allow conflicts among calls!):
> Error: value.f90, line 36: Incorrect data type for argument X (no. 1) of
> C_LOC_SUBROUTINE
>
> and from Lahey:
> 2204-S: "value.f90", line 35: In the reference to procedure
> C_LOC_Subroutine, the type of actual argument must be the same as that
> of the corresponding dummy argument.
>
> Intel does not complain, nor does Absoft. So I am not sure, and I know
> we had a related interp recently...
>
> I agree with Van that having typedefs like he described is most
> useful...
|