(j3.2006) (SC22WG5.4384) Discussion on TYPE(*)
Reinhold.Bader at lrz.de
Mon Dec 6 15:54:56 EST 2010
> On 12/6/10 1:03 PM, Aleksandar Donev wrote:
>> On 12/06/10 13:24, Bill Long wrote:
>> If we make that the case, then we have to also allow a C function to
>> call a BIND(C) Fortran subprogram that has a CLASS(*) dummy
> No we don't Bill. An interface with a CLASS(*) dummy is NOT
> interoperable and no one has proposed to make it so. An interface with
> TYPE(*) dummy is.
Agreed. The differentiator is that for BIND(C) only interoperable
stuff must be contained in the object (5.2.8 para 5) anyway, so
it doesn't make sense to allow more than TYPE(*) here.
>> The question is: Can the actual argument be CLASS(*)
>> or not.
>> subroutine sub(x) bind(c)
>> type(*), dimension(:) :: x
>> end subroutine
>> end interface
>> CLASS(*), ... :: x(:)
>> ! Is this allowed and what does the C descriptor get filled with?
> I do not see anything that prohibits this. For this to be valid, the
> actual argument would have to actually have a dynamic type at the point
> of the call below, and be allocated / pointer associated. So the basic
> information needed in the C descriptor seems to be available.
OK, so would we get the following for desc->type inside C
CFI_type_unspecified, if the object is not allocated/associated
CFI_type_int, if the object was allocated to INTEGER(C_INT)
CFI_type_struct, if the object was allocated to be of interoperable
>> call sub(x(1:10:2))
> Even call sub(x) seems OK here.
> However, if the dummy were allocatable or pointer, then for the sub(x)
> call, both the dummy and actual need to be "unlimited polymorphic".
> This is nominally the case if TYPE(*) is unlimited polymorphic, but I
> see this as one of those cases where the base standard might need
> modification to require CLASS(*) instead of "unlimited polymorphic".
With respect to which rule?
You also wrote earlier that
> However, if it is a C function calling Fortran with such an interface,
> reconstructing all of the CLASS infrastructure on the Fortran side from
> the information in the C descriptor might be problematic. There is no
> information about the struct's components in the descriptor.
Will it be necessary? For BIND(C) derived types this information is not
required under F2003. My conclusion is that you can simply allocate stuff
with CFI_allocate() within C if you deal with the descriptor case (the
only one relevant as long as we talk about POINTER/ALLOCATABLE) and things
should be OK if you also initialize the descriptor to the correct
intrinsic type, or the derived type indicator.
More information about the J3