(j3.2006) TKR for C Interop

[Aleksandar Donev]

On Wednesday 28 February 2007 11:29, Bill Long wrote:

> ?If the vendor does not support a field,
> it can be supplied as "not available" when going the other direction. 
It makes no sense to supply a half-standardized feature, that is, something 
that may only work on some compilers but not on others. Much better to simply 
not include such fields in the "other direction". If the user needs to keep 
track of TKR info, they can do it themselves, without relying that it be 
stored in the descriptor. That is robust for all compilers.

> Rather than have a separate routine to copy the C descriptor, the
> current plan is to include a visible component that has the total size
> of the struct (including the hidden components) in bytes. ?This allows
> the user to use existing means (malloc, memcpy) to duplicate one.
This is a problem because the size depends on rank. Some vendors (ex. NAG and 
Sun) do not store rank inside the descriptor. So they cannot return the size 
unless a rank is input.

If the size of the descriptor is available in some way, what is the purpose? 
Is it only to allow memcpy to be used? If this is the only purpose than a 
cloning routine in the API is better design.

Some people I showed the old design to complained that the routine to create 
descriptors requires dynamic memory allocation, that is, one cannot put the 
descriptor on the stack or some such. This was mostly because its size 
depends on rank. If we can find a way to allow declaring descriptors in C 
directly instead of via handles that would make the API easier. I don't think 
C supports parameterized types however...though C99 does have "flexible array 
members" which are awfully awkward to use...

BTW, which is this "current plan" you are referring to? Is there a paper that 
gives the latest API?

Aleks