Re: Ada GC (was Re: Ammo-zilla)

["Vladimir Olensky" <vladimir_olensky@yahoo.com>]

> >> > Robert Dewar wrote in message <7vvroo$grr$1@nnrp1.deja.com>...
> >> >But that of course is not enough to prevent scary GC bugs :-)
> >>
> >> Yes, I agree this does not prevent  GC bugs that may exist
> >> in GC implementation itself.  But at least that could  provide
> >> isolation between GC implementation and GC client.
> >> The last one will never be able to spoil anything in GC
> >> internal data.
> >
> >Again you miss my point, unless you segregate memory with
> >hardware memory protect, allowing unchecked conversion, and
> >hence address calculations, anywhere, can damage data structures
> >anywhere. I am NOT talking about bugs in the GC implementation
> >itself.
>
> With some overhead some measures could be taken to check pointer
> validity  to increase safety. This could be done by keeping
> (hashed) table/list of pointers to allocated objects  and
> use that table/list to check pointer validity . Here I should
> mention  very  interesting example in GNAT distribution, namely
> System.Debug_Pools package that makes use of  H-table to keep
> the status of each storage chunk used in that pool.
>
> Generally there could be many approaches to increase safety.
> One of the nice ones (for me)  is to use notion of safe and unsafe
> modules/packages as in Modula-3 and do not allow any unsafe
> operations in safe packages.


Below is a small illustration to the topic discussed.

When using unchecked conversions it is very easy to damage data
even without pointer arithmetic.

As there is no way now to check VALIDITY of the pointer
then after unchecked conversion the result of doing such
conversion could be very disastrous.

Even if we try to check validity of the object's fields
which  is referenced by the new pointer this does not
help sometimes. Moreover if that pointer is Null then we
will have Constraint_Error or Program_Error exception.

This shows that for the safety reason applicability area of
the T'Valid attribute could be expanded at the expense of
some overhead in storage pool management to include validity
check for the given pointer that could be done as was
discussed in the previous posts.


Regards,
Vladimir Olensky

----------------------------------------------------
-- Demo:
-- Unchecked_Conversion -- bad usage that results in
-- data corruption
----------------------------------------------------

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
with Ada.Unchecked_Conversion;

procedure Tst_Acc_Validity is

   type T is
      record
         A : Integer;
         B : Integer;
      end record;

   type T_Ptr is access all T;

   type Enum is
         (Mon,
          Tue,
          Wed);

   package En_IO is new Ada.Text_IO.Enumeration_IO(Enum);

   type S is
      record
         A : String (1 .. 10) := " test test";
         B : Enum             := Tue;
      end record;

   type S_Ptr is access all S;

   function T_To_S_Ptr is
   new
      Ada.Unchecked_Conversion(T_Ptr,S_Ptr );

   T1 : T_Ptr;
   S1,
   S2 : S_Ptr;

begin

   T1 := new T'(
     A => 177,
     B => 555);

   S1:= T_To_S_Ptr(T1);

--   if S1'Valid then  ....
     --  no way do do this now, won't compile

   if S1.B'Valid then
      Put_Line(" S1.B is valid");
   else
      Put_Line(" S1.B is not valid");
   end if;
   --  does not show that S1.B is invalid

   New_Line;
   Put_Line("------------------------              Uncorrupted T1:");
   Put(" T1.A = ");
   Put(T1.A);
   New_Line;
   Put(" T1.B = ");
   Put(T1.B);
   New_Line;

   Put_Line("--------------------- Reading S1 from T1 memory area:");
   Put(" S1.A = ");
   Put(S1.A);
   New_Line;
   Put(" S1.B = ");
   En_IO.Put(S1.B);
   New_Line;

   S1.A:="write test";
   S1.B:=Wed;

   Put_Line("----- Writing S1 to T1 memory area and reading again:");
   Put(" S1.A = ");
   Put(S1.A);
   New_Line;
   Put(" S1.B = ");
   En_IO.Put(S1.B);
   New_Line;

   Put_Line("T1 is corrupted  after assigning values to S1 fields:");
   Put(" T1.A = ");
   Put(T1.A);
   New_Line;
   Put(" T1.B = ");
   Put(T1.B);
   New_Line;


   Put_Line("----------------------------- Checking S2.B validity:");
   --  could result in erroneous execution
   --  (LRM 13.11.2 (16): Evaluating a name that denotes a nonexistent
   --   object is erroneous)
   --  or raise Constraint_Error at a run time
   if S2.B'Valid then
      Put_Line(" S2.B is valid");
   else
      Put_Line(" S2.B is not valid");
   end if;


end Tst_Acc_Validity;


=============================================================
Progam output:

 S1.B is valid

----------------------------------              Uncorrupted T1:
 T1.A =         177
 T1.B =         555
------------------------------- Reading S1 from T1 memory area:
 S1.A = _   +\x02
 S1.B = MON
--------------- Writing S1 to T1 memory area and reading again:
 S1.A = write test
 S1.B = WED
--------- T1 is corrupted  after assigning values to S1 fields:
 T1.A =  1953067639
 T1.B =  1702109285
--------------------------------------- Checking S2.B validity:

raised CONSTRAINT_ERROR : tst_acc_validity.adb:95