(j3.2006) TKR for C Interop
Wed Feb 28 14:43:51 EST 2007
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?
More information about the J3