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

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

[Michel Gauthier]

This is essentially a question to gurus.

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 ?

To avoid flames and useless answers, I add that :
 - I am aware that pointers have no meaning if re-read from a file _written 
in another execution_ of the program (in fact, formally, they are references to 
already destroyed objects, hence in principle indistinguishable from null),
 - the problem occurs _in a low-level layer_ of the programme, but
portability is preferable,
 - what I need is exactly an end-of-sequence boolean information, which
can be implemented evenly at a price that is unpleasant so deeply in 
the programme.

So, I'd like to know if there are arguments in favor of or against my
assumptions in Ada texts like 'implementation advice' sections, 
URG work, code-generator documentations, or whatever.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone + 33 5 55 45 73 35  [or ~ 72 32]
fax +33 5 55 45 73 15  [or ~72 01] 
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------

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

[Samuel Tardieu]

Michel> This is essentially a question to gurus.

This kind of sentence does not ensure an answer :-)

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

Well, you can turn it into a reasonable assumption if your compiler
follows the Implementation Advice given in 13.13 (7):

 "If a stream element is the same size as a storage element, then the
 normal in-memory representation should be used by Read and Write for
 scalar objects. Otherwise, Read and Write should use the smallest
 number of stream elements needed to represent all values in the base
 range of the scalar type"

Let me explain:

Pointers are not a scalar type, but you can define your own 'Read and
'Write attributes for the pointer types you define[1]. The 'Write
logic can then be:

  if pointer is null then write the boolean True to the stream
  otherwise write the boolean False then the pointer itself[2]

(the 'Read attribute is then straightforward)

If your compiler follows the implementation advice indicated above,
then it will ensure that in the case of a null pointer, you will have
a fixed size output since you will output a value of a scalar type in
the stream (True). Note that for a non-null pointer, it is still
undefined (furthermore, it is likely that it will be greater given
than one boolean and one pointer will be written to the stream).

Note that in practive, it is likely that your compiler use a fixed
size for a given access type, so all this discussion is probably
pointless.

To summarize, it is possible if you can find one particular value of
one particular type which gets written using a maximum number of bits
each time (you just write this particular value instead of a null
pointer and another one of the same type before a non-null pointer).

I'd be interested to know if this is possible to assume this without
this assumption.

  Sam

Footnotes: 
[1]  If you do not have the possibility to redefine attributes because 
     for example the pointer type is given as a generic formal, then
     you can create a new pointer type derived from the first one and
     redefine 'Read and 'Write for the new one. Then you use
     conversions between the two types when willing to write and read
     an element.

[2]  You will define yet another pointer type with standard Read and
     Write attributes for this one, to avoid calling your 'Write
     attribute recursively.
-- 
Samuel Tardieu -- sam@ada.eu.org

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

[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