(j3.2006) (SC22WG5.4370) [ukfortran] WG5 informal ballot re Interop. TR

Bill Long longb
Mon Dec 6 11:20:35 EST 2010

On 12/6/10 7:41 AM, Aleksandar Donev wrote:

>> A reasonable alternative would be to
>> forbid passing TYPE(*) actuals to TYPE(*) dummies.
> This is too drastic. We want to disallow TYPE(*) assumed-shape or
> explicit-shape dummies (that is, ones that do not carry a descriptor) to

I assume you meant assumed-size, since assumed-size and explicit-shape 
are the non-descriptor modes.  However, one of the original desires of 
the MPI users was to have


map to a void * dummy parameter and have only the address passed.  I 
think this would be an often used form.

> be passed as actuals for TYPE(*) dummies. That way, we ensure that type
> information is always present. One can still write wrappers in Fortran
> that have TYPE(*) dummies, but they will always be assumed rank. C
> routines on the other hand can avoid descriptors, but can also rely on
> having type information.
> Does this seem acceptable?
>> If we go for the "forbid" route, I hope
>> that we can pass CLASS(*) actuals to TYPE(*) dummies - and that if this
>> ends up in a C descriptor that the descriptor fields "type" (if we keep
>> that) and "elem_size" (and "length" if we get that) are set
>> appropriately. In fact I think we can do that anyway as the TR stands.
> Yes, CLASS(*) or in fact any polymorphic thingo that already carries a
> hidden type descriptor could be allowed as an actual argument
> corresponding to a TYPE(*) dummy. But we need to decide this and put it
> in writing in the TR.

If you are looking at Fortran calling C, then allowing CLASS(*) dummies 
could be doable - in practice the type will always by a struct.  We 
would still want to limit type parameters and type-bound procedures.

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.


Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

More information about the J3 mailing list