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: 
 g2news1.google.com!news2.google.com!news.glorb.com!news.mv.net!nntp.TheWorld.com!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: A hole in Ada type safety
Date: Sat, 30 Apr 2011 07:56:40 -0400
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wccoc3oq7ev.fsf@shell01.TheWorld.com>
References: <87oc3odtci.fsf@mid.deneb.enyo.de>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: pcls6.std.com 1304164600 29088 192.74.137.71 (30 Apr 2011 11:56:40
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Sat, 30 Apr 2011 11:56:40 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:5k9yU5txUkMB/oT14M1rs90kQtg=
Xref: g2news1.google.com comp.lang.ada:19100
Date: 2011-04-30T07:56:40-04:00
List-Id: <comp.lang.ada>

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.

> When the inner function Convert is called, the discriminant Sel of M
> has the value Target_Field, thus the component M.T can be
> dereferenced. The assignment statement in Convert changes the
> discriminant and the value. But the source value S is still reachable
> as an object of type Target because the parameter T aliases the
> component M.T, so the return statement executes without raising an
> exception.

Well, the program exhibits erroneous (i.e. unpredictable) behavior,
so anything could happen.  The above description is likely to happen.

> 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.

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.

- Bob