Hello,
Is the EXTERNAL-ness the problem?
Fortran doesn't disambiguate on the basis of externals,
does it?
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
On Thu, 9 Sep 2004 17:17:17 -0700, [log in to unmask] wrote:
>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...
|