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: 545143557 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>... >In article , > "Vladimir Olensky" wrote: >> >> Robert Dewar wrote in message <7vqd45$iiq$1@nnrp1.deja.com>... >> >In article , >> > "Vladimir Olensky" wrote: >> >> As for me I fully support that. >> >> I think that any unchecked conversions should >> >> be disallowed for pointers that are traced by GC. >> >> It is not only extremely unsafe but I do not see any sense >> >> in that if language is extended to support GC. >> > >> >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. I see your point now. Of course it is very dangerous to perform any calculations (e.g address arithmetic) for something that is hidden behind protection wall and one does not know for sure what is there in reality. This is especially dangerous when different kinds of memory pools are mixed and one does not know for sure on which kind of memory one is trying to perform such operations. It just never come to my mind that someone (one the client's side) could try to do something (using unchecked conversions ) for anything that is behind that protection wall (for me it is a crazy idea). Mapping between external world and internal world relative to that wall could only be allowed to the subsystem responsible for that protection wall. As a matter of fact I do not see the way how one can penetrate in reality through hardware memory protection wall directly using pointer arithmetic. One need to have access to some system resources to do that. But if one could perform such operations with the virtual addresses on this side of the wall and if one does not know how they map to the real physical addresses it could cause problems. On the other hand you already pointed out the way to reduce that danger: ".. unless you segregate memory with hardware memory protect ..". Here I could also add that I think that it is not too dangerous to perform address arithmetic within single allocated chunck of memory providing that measures have been taken to ensure that the result is within memory boundaries of the allocated memory chunck. Reading/Writing data using such resulting address could be dangerous of course. It could be extremely dangerous to use address arithmetic trying to calculate location of the prev/next memory chunk or object in the memory if allocated memory chunks are not contiguous that could be the case when using hardware protected memory. In the best case one will get GPF, in the worst case one may damage data structures. With some overhead some measures could be taken to check pointer validity to increase safety. This could be 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_Pool 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. Regards, Vladimir Olensky