Re: 'is-null' property through file keeping (to gurus)

[bobduff@world.std.com (Robert A Duff)]

In article <gauthier-2904971634240001@193.50.185.13>,
Michel Gauthier <gauthier@alphainfo.unilim.fr> wrote:
>To avoid complex generic parameterising, I have made the assumption that
>the property 'this pointer is null / not null' is invariant when a pointer is
>written into then read from a file. Another view of the same is 'the null
>pointer has only one machine implementation and what is kept in a file is 
>no more than a fixed-sized bit sequence'. 
>Can this be a reasonable assumption ?

The language certainly doesn't guarantee anything about this.  RM-A.7(6)
says "The effect of input-output for access types is unspecified."  It's
not erroneous, so if you're willing to put up with potential
non-portability, and your implementation does what you want, and
documents that fact, then you might be able to do it.

Most implementations probably use a single representation for null.
However, that's certainly not required, and I can imagine an
implementation of null that actually points at something, and that
something is moved around by a garbage collector or some such thing.
Not all that likely.

It's hard for me to imagine that you really want null to behave itself,
but you don't care about any *other* access values.  Is that really what
you're saying?

As to other access values, within the same program run, they are likely
to be sensible across I/O if there's nothing fancy like garbage
collection going on.  (A gc might deallocate something whose only
remaining pointer is in the file, or it might move things around in
memory, and fail to update the pointer that lives in the file.)  I mean,
if you don't deallocate the stuff that is referenced from the disk file.

You might be able to get a bit more low-level control if you write your
own storage pool type.  There's also pragma Controlled, which turns off
garbage collection.

- Bob