(j3.2006) TKR for C Interop

[Van Snyder]

On Wed, 2007-02-28 at 19:29 -0600, Bill Long wrote:
> 
> Aleksandar Donev wrote:
> 
> >
> >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.
> >  
> >
> 
> I do not see how this sort of binary compatibility is possible in any 
> reasonable way.  Vendor dope vectors have different formats, so the size 
> of the corresponding C descriptor will be different from one Fortran 
> compiler to the next. Unless you want the C struct to include separate 
> regions for each vendor's specifics, in which case the struct will be in 
> the 1000+ word range. And all the vendors have to agree on the layout, 
> and they would be prohibited from changing their dope vectors in the 
> future.  I'm seeing epsilon probability here.  Calling sequence 
> conventions are not even necessarily the same among Fortran compilers.  
> A Fortran implementation can interoperate with the C compiler specified 
> at compile time, but that's it.  This is true of the current interop - 
> nothing special about the new extensions.

I think Bill is making the same mistake that has been made many times in
discussion of C interop, and especially the current TR.  The problem to
be solved is not how to represent every vendor's dope vector for every
context of procedure reference.  In particular, the interop TR has
nothing to do with how vendors represent arguments for procedures that
aren't interoperable.  The goal of the TR is (I hope!) only to specify
how arguments for interoperable procedures are represented.

I assume that even without this TR, vendors are free to represent
procedure references (and their arguments) differently depending upon
whether they're interoperable.  I hope the TR would not detract from
that.

-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder at jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.