From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: "Vladimir Olensky" Subject: Re: Ada GC (was Re: Ammo-zilla) Date: 1999/11/06 Message-ID: #1/1 X-Deja-AN: 545211832 References: <38120FAF.945ADD7D@hso.link.com> <7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com> <38189268.43EB150F@mail.earthlink.net> <86ogdjtdwz.fsf@ppp-115-70.villette.club-internet.fr> <7vadsp$8q61@news.cis.okstate.edu> <1999Oct28.221910.1@eisner> <7vb3c4$8a21@news.cis.okstate.edu> <7vhg2n$7ht$1@nnrp1.deja.com> <7vkjea$b34$1@nnrp1.deja.com> <7vncgr$bpg$1@nnrp1.deja.com> <7vqd45$iiq$1@nnrp1.deja.com> <7vvroo$grr$1@nnrp1.deja.com> Organization: Posted via Supernews, http://www.supernews.com X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Newsgroups: comp.lang.ada X-Complaints-To: newsabuse@supernews.com Date: 1999-11-06T00:00:00+00:00 List-Id: > >> > 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 = _ + 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