On Tue, 31 Aug 2004, Peter W. Draper wrote:
> your explanation seems to reflect pretty much what I remember of these
> discussions (which I wasn't directly involved in either), but there surely
> is a problem with this idea of returning what will be an arbitrary pointer
> to the address space of the process. Yes, 1 and 2 and so on will probably
> code dump, but that's not guaranteed, I think 0 is the only valid, invalid
> pointer. The safe way to create an invalid pointer must be to allocate
> some memory and then deallocate it.
Except with %LOC that can't be done. You have no choice. The whole driver
here is that for %LOC to be able to register pointers with CNF such that
other places in the code can safely use CNF_PVAL, we need to be able
to register an arbitrary pointer value uniquely.
I've got something working that can EITHER do the clever masking
OR some kind of unique hash generator (uses CRC32), which in principal
is fine but the real tricky bit is that the way that CNF is written,
it is hard to use the masking scheme for "normal" pointers, and the
alternative scheme for %LOC pointers. CNF has a one-way C-to-Fortran
function which is continually run on all the available C pointers in
order to look for clashes. This doesn't allow a "run through the check
using masking, if that fails use hashing" approach.
Having a new flag to Register is the easy bit (just switch in the
C-to-Fortran macro). Deciding which technique was used to store the
pointer is the hard bit.
Maybe I need to make cnfFptr/cnfCptr run through twice (we would probably
have to make sure that Register did not cause a clash though :-( )
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|