(j3.2006) TKR for C Interop

[Aleksandar Donev]

On Thursday 01 March 2007 08:16, Bill Long wrote:

>  If you want a universal library, you have to block inlining of these
> procedures.? Similarly, the include file used by the C function will be
> vendor supplied.?
I said earlier:
On Wednesday 28 February 2007 17:05, Aleksandar Donev wrote:
> 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.

So:
1) There is a "default" header file that is fully specified by the standard. 
That is, even the values of constants such as "invalid rank" are specified by 
us, not left as named constants.
2) The vendor is free to replace the include file with its own for efficiency 
etc. But it is also required to support the default one.

I am not saying this should be a requirement. It is lower on the list of 
priorities. But, if possible, I see it as a good thing. In the C world I 
don't see much of it in the standards themselves, but behind the scenes I see 
ABIs appear and implementations following them even though they are not 
required by the standard. For example, on my system (Linux x86_64), there are 
several GLUT (from OpenGL) libraries but they all try to use the same values 
for predefined constants (say GL_ENABLE) so that there is binary 
compatibility and one can switch (shared) libraries without recompiling 
applications. It works nicely.

Aleks