On Thu, 17 Aug 2006, Tim Jenness wrote:
> On Thu, 17 Aug 2006, David Berry wrote:
>
> > 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.
> >
>
> Are you proposing that we make changes to the keoe branch?
No. Maybe for a future release, but not this one.
> There is now
> quite a bit of C code that has been modified to use NULL instead of
> (char*)DAT__ROOT.
If the use of NULL to represent DAT__ROOT in C is now well established
then maybe we should just live with it. In practice it is unlikely to be a
problem since if a "DAT__NOLOC" NULL is supplied to ndfPlace, then I think
it is a reasonable assumption that an error will already have
occurred, resulting in the inherited status being set, resulting in
ndfPlace returning without action. In other words, if a NULL locator is
supplied to ndfPlace AND no error has occurred, then it is a pretty safe
bet that the NULL is meant to be "DAT__ROOT" rather than "DAT__NOLOC".
It would just be nice to know for sure though...
> One solution would be for something like this in dat_par.h:
>
> static const HDSLoc * DAT__ROOT = (HDSLoc *)(0x1); /* some random invalid pointer */
I guess this would be safe enough, since these pointers presumably never
get de-referenced anywhere other than in the HDS locator conversion code.
> Another may be to define a const global in HDS and then declare it as
> extern in dat_par.h. Then we could have it as a (HDSLoc*)"DAT__ROOT" but
> it wouldn't matter since we would just compare the pointer to DAT__ROOT
> not the contents.
A tad more security in this maybe, but more complicated.
David
|