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" <vladimir_olensky@yahoo.com>
Subject: Re: Ammo-zilla
Date: 1999/11/03
Message-ID: <s20tckqd24291@corp.supernews.com>#1/1
X-Deja-AN: 544029557
References: <38120FAF.945ADD7D@hso.link.com>
 <slrn8156pm.pl.aidan@skinner.demon.co.uk> <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>
 <wcc66zmnw0h.fsf@world.std.com> <7vkjea$b34$1@nnrp1.deja.com>
 <wcck8o0yh5x.fsf@world.std.com> <7vncgr$bpg$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-03T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert Dewar wrote in message <7vncgr$bpg$1@nnrp1.deja.com>...
>In article <wcck8o0yh5x.fsf@world.std.com>,
>  Robert A Duff <bobduff@world.std.com> wrote:
>>  Bugs in the GC itself have exactly the same sort
>> of nasty consequences we're talking about.
>
>Absolutely! And that's what's scary! These bugs in the GC itself
>are among the most horrible bugs I have ever tackled (the one
>exception being subtle hardware design errors). The idea that
>an Ada user with little awareness of what is going on at a low
>level can create bugs of comparable scariness by casual
>incorrect use of unchecked conversion seems unacceptably
>risky to me.


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.

Any manipulations with such pointers should be allowed only
within GC manager package. GC client should not have any access
to such operations at all. GC mechanism should be completely
hidden from the client. Depending on particular GC
mechanism any pointer traced by GC may be not only a pure
"ROOT" (in traditional GC terminology)  which  references object
storage location but it may also be a reference  to the entry
record in GC Address Descriptor Table which in turn in one
of it's fields contains  the real "ROOT" of the pointers tree/net
as well as other necessary fields (referenced object tag, size etc.).
Last approach  was described in my other posts.
For such GC_Pointer unchecked conversions done by
the client makes no sense at all.

This restriction could be done using  language support for GC.
Let's suppose that we have additional keyword TRACED
that applied to the ACCESS TYPES controlled by GC.
(This TRACED ACCESS TYPE could be bound
to particular GC using standard Ada construct:
for T'Storage_Pool use Ada.GC.GC_Name_Storage_Pool).

When access type is declared to be traced compiler should
not allow any unchecked conversions with that type in standard
mode.
In may allowed only using  additional pragmas.


Regards,
Vladimir Olensky