(j3.2006) TKR for C Interop

[Aleksandar Donev]

On Wednesday 28 February 2007 15:58, Bill Long wrote:

> The simplest is fixed size.? In the worst case I can think of, this could
> be ~140 64-bit words, though for vendors that support higher than rank 15
> it could be even more.? Do you think this would be acceptable?
I'd prefer if we examine other options more carefully before committing. Here 
are some alternatives, in order of increasing dislike:
1) Separate the "header" from the "dimension-specific" bits into two different 
structs. The header is fixed size, and the strides etc. are given as an array 
of 3-integer structs.
2) Use different types for each rank, say Descriptor_1, Descriptor_2, etc.
3) Use flexible array members from C99.

The Fortran descriptors are done via handles anyway, so they can be 
"incomplete types", that is, essentially manipulated via pointers. If we want 
to allow memory for them to be on a stack we can allow/require the user to 
provide the memory (we'd need a way to tell them how much memory is needed of 
course) for the descriptor in the creation routine. That routine would merely 
fill in the values and not do memory allocation. This does not seem too 
important, but it does help with memory leaks and efficiency.

I believe that an important goal of interop TR should be binary compatibility. 
That is, I believe one should be able to compile a C routine and then switch 
different Fortran compilers (and libraries of course) without recompiling 
(and vice versa). If the C struct is fully specified (no opaque components), 
and the handles for the Fortran descriptors are pointers (void *), I think we 
have achieved that goal. Essentially the whole TR header file will be 
specified from Fortran, and the vendor will only provide the library that 
implements the specified API. For efficiency, we may want to allow a vendor 
to replace the header file with something that makes the routines macros, for 
example.

Aleks