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/04 Message-ID: #1/1 X-Deja-AN: 544498033 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> 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-04T00:00:00+00:00 List-Id: 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. Also, approach that I discribed yearlier provides additional level of isolation between GC user and GC internal data representation and it also allows to achieve any desired level of sofisticated functionality . Any pointer of "TRACED" ACCESS TYPE should never reference real data. Instead it should only provide access to the Address Descriptor Table entry for the allocated object . Moreover, Address Descriptor Table structure is completely hidden from the user. This is the same as protected memory access in OS running in protected mode. This already proved to be very effective in providing safety and reliability. >As soon as you allow the type safety of the system to be >compromised in any way, it is possible that critical pointers >will get damaged. Again I agree here. And again I would like to recall neat Modula-3 approach to the safety issues that could also be very useful in Ada: Any unsafe operations are allowed only in the modules marked as UNSAFE . This marker says that here programmer and not the system is responsible for safety. In modules without such marker M3 does not allow any unsafe operation and safety is guaranteed by the system itself. Such approach force all (potentially) unsafe operations to be concentrated in few unsafe modules instead of being scatted around. Right now nothing forces Ada programmer (except his/her internal discipline) to concentrate all unsafe operation in special packages. This reminds me discussions Ada vs. C& C++ where many times many people were telling that Ada is better in this respect than C++ as C++ does allow to use unsafe and dangerous C style programming and does not force to use new more safe C++ features. Yes, Ada is much safer itself but it does not force as Modula-3 to put unsafe code in special places where such operations could be easily traced and managed. I think that some ideas implemented in M3 could be very useful in Ada . There is nothing bad in using other's positive experience. Here I could remind that Component Pascal (descendant of Oberon-2) accepted some nice Ada features and they state that Ada positive experiences were taken into account and that sounds good for me. Regards, Vladimir Olensky.