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...
Thanks,
Aleksandar
|