On Thu, 17 Aug 2006, David Berry wrote:
> On Thu, 17 Aug 2006, Peter W. Draper wrote:
>>> Would it not be better to have a separate way of representing DAT__ROOT in
>>> the C interface?
>> Of the NDF library, maybe it's only used in one routine in HDS itself, but
>> that would break backwards compatibility?
> It seems reasonably that it should be possible to distinguish between
> DAT__NOLOC and DAT__ROOT in C, but I suppose you are correct that any
> existing code that uses NULL to represent DAT__ROOT would break if we now
> reserved NULL exclusively for DAT__NOLOC.
Not sure I understand what you gain from being able to distinguish
DAT__NOLOC from DAT__ROOT. I was treating it as purely a fortran construct
(which had to use the string hack and had no NULL). Have you run into an
error state where NDF was given something you thought was a good locator
but was in fact NULL (with good status) and so didn't actually complain?
I think in HDS only HDS_FIND uses it (and that's not got a C interface
yet). I was actually surprised to find that DAT__ROOT was defined in
DAT_PAR at all given that it was only used in NDF (until I imported
HDS_FIND from NDF).