> >>> Should have said that this is one of the points that David was making about
> >>> the memory handling in AST.
> >>>
> >>
> >> but wouldn't I be dereferncing the pointer to work out whether the check
> >> bit is set? How is that different from dereferencing the pointer to obtain
> >> the first few characters?
> >
> > True. AST would bomb if you supply a pointer to un-referenceable memory,
> > if it were not for the inherited status check which occurs at the
> > start of most AST functions. It assumes that truly bad pointers can only
> > be supplied if an error has already occurred, in which case the global
> > status will be set.
>
> Clearly I was ascribing properties to AST that it doesn't have. Looking
> closer I see it just checks that the memory pointed at hasn't been
> corrupted since allocation and not that the pointer is also valid.
>
> If we want to check the pointer validity we'd clearly need to keep a table
> of these when allocated and check the value of any returned pointers
> against this list before dereferencing. A chore that CNF nearly does (for
> 64 bit pointers)? Maybe now that all the locators are being _call()
> checked for validity my heightened HDS alert state will reduce...
This is what AST does, but only for the public interface. The "pointers"
returned by the public interface for AST are not genuine pointers at all,
but integer object handles packing into pointer form. On entry to any
public AST routine, the handle is extracted from the supplied pointer
value and checked for validity. If it is valid, the *real* pointer is
extracted from a table of pointers, using the handle to index the table,
and the real pointer is then used throughout the private AST functions.
Internally, the only functions which do any checks before using a pointer
are the low-level memory-management functions such as astFree, astGrow,
astStore, etc. These dereference the supplied pointer and check that the
magic value stored with the memory block is correct.
David
|