It took a couple of days but I've just committed the updates to the C HDS
API. All routines that require HDS Locators now have to use an HDSLoc* and
all routines that generate HDS locators now take an HDSLoc**
eg.:
int
datCoerc(HDSLoc *locator1,
int ndim,
HDSLoc **locator2,
int *status);
See hds.h for details. The HDSLoc struct itself is private and is not
known to the public API.
This has required an *extensive* rewrite of the locator interface. It
wasn't that complicated given that I am just providing a public interface
to struct LOC which already existed privately, but all uses of the
DAT__SZLOC buffer have been expunged from the C side and now only exist in
fortran_interface.c. There are routines to convert the Fortran buffer to C
that are only allowed in the fortran interface.
What this means is that things may break in the Fortran side. I've done a
make check for NDF and HDS, used hdstrace on a load of files I had lying
around, run up kappa stats and done make test from perl NDF and this all
seems to work. I can't guarantee to have checked every HDS Fortran routine
with this though since there is no comprehensive fortran HDS test suite
(although I think Brian was offering to check one in).
C applications that use the fortran layer will still work
since DAT__SZLOC is still available to them. Next step is to start working
through the CVS code replacing C fortran API with C API. Followed by
changing NDF to use HDSLoc in its routines that export locators.
The global price for all this is that each time a locator is returned an
extra malloc is required. The up side is that we now have type safety
from C and every call from C has now saved a memcpy since it is using the
struct directly.
David, sorry about breaking cupid. I just noticed that it uses an array of
DAT__SZLOC locators from C. Hopefully the fix should make things a bit
easier (an array of pointers is now all that is required).
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|