Re: A hole in Ada type safety

[Robert A Duff <bobduff@shell01.TheWorld.com>]

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