Re: Which is right here - GNAT or OA ?

[Florian Weimer <fw@cygnus.stuttgart.netsurf.de>]

"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:

> When Free(X) is invoked then RTS  could do something like this  (in reality
> it may be much more complex):

[Heuristics based on the internal access value representation snipped]

> Such solution have very little  overhead and it is not very difficult to
> be implemented.

Maybe that's true, but it does not work.  Consider the following
situation:

   type A is record
      X: Integer;
   end record;

   type B is record
     Y: aliased A;
   end record;
   
   type B_Access is access B;

   Z: B_Access := new B;
                        
Your heuristics fails for Z.Y'Access, because this access
value references an object which has been created indirectly by
an allocator.  On all architectures I can imagine, the internal
machine representation of Z.Y'Access will look very like that of an
access to an object which has been directly created by an allocator,
although the value of Z.Y'Access certainly isn't a valid argument for
Ada.Unchecked_Deallocation.

Of course, it is possible to ensure that Ada.Unchecked_Deallocation
raises an exception if it encounters an access-to-variable, but this
requires some non-trivial changes.  A few possible implementations come
to my mind: colored pointers, fat pointers, hidden record fields (your
suggestion; problematic with scalar types and possibly with records
with representation clauses, also some space concerns), colored tags
for tagged records, support from a garbage collector.  They all don't
seem very appealing to me and probably won't handle all kinds of Ada
objects consistently (except perhaps garbage collection ;).

One very reasonable way to solve this kind of problem was already
pointed out: Use an abstract data type which hides allocation and
deallocation details in the implementation.  This way, you never have to
call Ada.Unchecked_Deallocation directly (outside the implementation,
of course), and you can't accidently deallocate an object which isn't
located in a storage pool.