Calling Fortran from C code - derived types with pointers

[lacek]

Dear All

I am trying to link existing, large Fortran code to python. I decided to utilize very good Python-C interoperability and link Fortran code with C wrapper first.

I have a proble with the following typedef: 

type, BIND(C) :: type_state
    complex*16, dimension (:,:,:,:),allocatable :: g
    (...)
end type type_state

I have deleted the rest, as there are there a few integers and arrays. According to Intel Compiler manual, and Fortran 2003 specification, derived types may not contain pointer and allocatable arrays (but may fixed size arrays) to be interoperable with C struct contruct. Is there any way to go aroud the problem? Under some conditions this type should be mappable into "extern struct" with  appriopriate number of pointers and integers inside it, but I suppose this is poorely portable.

The target machines are simple PCs with at most 2 modern Intel processors, working under linux (red hat, debian or Ubuntu).

[Steven_L_Intel1]

Not only are deferred-shape arrays not interoperable, but multidimension arrays aren't either. (There is a proposal for Fortran 2015 that would allow some limited interoperability of deferred-shape and allocatable arrays.) How is this array declared in C/Python? You could put a TYPE(C_PTR) component there and assign it the C_LOC of the array - that would share a C pointer to the array data.

[lacek]

At present it is not defined. It seems I was not so clear. The code is presently written in Fortran (without iso_c_binding and bind). I was going to call it from C, and the C function from python. I am very flexible as fas as the possible definition of the array in C is concerned, as I have not yet done it. Actually I was not playing with the above code, but with a "toy model" - containing only a one dimensional allocatable. I was going to map it to complex * or complex * or double * (in the last case I suppose I would have to treat imaginary an real part separately). I assumed that in the multidimensional case I will also map it to the rank-one C pointer (but not to double **** as this makes no sense). by some standard lexicographical ordering on indices of the matrix. From You have written it seems that it is possible to use C_PTR as a middle step between "full Fortran" pointer and "C ponters in C Code". The suggestion that you make seems very natural. Perhaps I do not understand it. It seems very natural, but it was not included in the standard. Why?

[jimdempseyatthecove]

>>You could put a TYPE(C_PTR) component there and assign it the C_LOC of the array - that would share a C pointer to the array data. And you my also wish pass the rank and shape of the array (if that is pertinant to the interface). Jim Dempsey

[Steven_L_Intel1]

lacek wrote:

From You have written it seems that it is possible to use C_PTR as a middle step between "full Fortran" pointer and "C ponters in C Code".
The suggestion that you make seems very natural. Perhaps I do not understand it. It seems very natural, but it was not included in the standard. Why?

But it was included! C_PTR is defined by the standard as is C_F_POINTER and C_LOC. With these you can "convert" freely between C and Fortran pointers. This is all part of the C interoperability feature of Fortran 2003.

[lacek]

I meant something else. What you described seems quite conviniet way to go aroung interoperability limits: rendering multidimensional arrays, and typedefs with pointer or allocatables uninteroperable. Actually it sounds very convinient. So why exactly are those two cases excluded from interoperability?

[Steven_L_Intel1]

Multidimensional arrays are excluded because C has no such thing. In C, what looks like a multidimensional array is an array of pointers to arrays, not a Fortran concept. Deferred-shape arrays are not interoperable because it requires some sort of descriptor to be passed and there's not yet any standard specification for what that might be. TS29113 for "Enhanced C Interoperability" does define a standard descriptor type, but that would mean the C code needs to use the provided facilities to "decode" the descriptor.

[lacek]

I see, thank you for all help and the replies. I underestimated the similarity level of structures required by interoperability. Thanks for TS29133.