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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,3a7c118fd2cc64f9
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news2.google.com!news.glorb.com!feeder.erje.net!news.szaf.org!news.gnuher.de!news.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: A hole in Ada type safety
Date: Sat, 30 Apr 2011 18:16:40 +0200
Message-ID: <87tydfbtp3.fsf@mid.deneb.enyo.de>
References: <87oc3odtci.fsf@mid.deneb.enyo.de>
	<wccoc3oq7ev.fsf@shell01.TheWorld.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ruchba.enyo.de 1304180202 19377 172.17.135.6 (30 Apr 2011 16:16:42
 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:sS3Cb+KIC1BRuU1L42g1dCHYod4=
Xref: g2news2.google.com comp.lang.ada:20074
Date: 2011-04-30T18:16:40+02:00
List-Id: <comp.lang.ada>

* Robert A. Duff:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> I don't know if this is a new observation---I couldn't find
>> documentation for it.
>
> It's not new.  It is documented in AARM-3.7.2(4,4.a),
> which dates back to Ada 83 days.

Ah.  I didn't realize that call to Convert was already erroneous.

It does not seem possible to extend the restrictions on 'Access
prefixes to to subprogram parameters (due to the way controlled types
are implemented, for example).

>> Our implementation lacks the full power of Ada.Unchecked_Conversion
>> because it does not supported limited or unconstrained types. However,
>> it is sufficient to break type safety.
>
> Yes.  Anything that is erroneous necessarily breaks type safety.
> If you look up "erroneous execution" in the index, you'll find
> them all.

My concern was that this was not explicitly labeled as erroneous. 8-)

> Your comment, "This note shows that a combination of safe-looking
> language features can be used to undermine type safety, too."
> is the key point.  It is indeed unfortunate when "safe-looking"
> features can be erroneous.

And once there is something like this in the language, it is difficult
to decide if a new addition (such as aliased parameters) make things
worse or not.