Re: A hole in Ada type safety

[Florian Weimer <fw@deneb.enyo.de>]

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