Tim,
DAT__ROOT and DAT__NOLOC have different notional meanings; one is a
valid locator to the root of the file system, and the other is an invalid
locator. Supplied with DAT__NOLOC, ndf_open would report an error, but
supplied with DAT__ROOT it would function as normal. At the moment,
ndfPlace cannot distinguish these two cases.
David
On Thu, 17 Aug 2006, Tim Jenness wrote:
> 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).
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
|