Re: A hole in Ada type safety

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

* Randy Brukardt:

> Actually, I think T.T'Access is illegal, because the component T is not 
> declared as aliased. You can take 'Access of the parameter T, but not of 
> some random component (as is currently the case in Ada).

Wouldn't it work if the component T was aliased?

> But this looks like an attempt to shot yourself in the foot; it's hardly 
> likely to happen by accident. Remember that no programming language can 
> really defend against malicious programmers; the point is to defend against 
> sloppy or careless programmers [which is all of us, sooner or later].

My first answer that was rather confrontational.  Let me just say that
this is the line of argument used by C advocates.

> For instance, the tampering checks of the Ada containers implicit in
> the new Reference routines can be defeated by the use of
> Unchecked_Deallocation on the return object. But this is not
> something that is reasonably going to happen by accident, and it is
> out in the open for program reviewers (both tools and humans) to
> find. It's not worth worrying about.

It's true that use-after-free errors typically result in exactly the
same type safety violation.  But they seem to be rather hard to spot
in COTS software, and I'm not sure that the programming languages are
to blame.  Manual memory management is just hard.

>> It seems to me that you need a C++-like rule that accessing an object
>> through a view which is not compatible with its dynamic type is
>> erroneous.  And this would be quite a defeat.
>
> But that's exactly what 3.7.2(4) is. And it has been in Ada since the 
> beginning.

3.7.2(4) has very precise syntact requirements ("a name denoting a
subcomponent that depends on discriminants" etc.).  I don't think it
covers the new possibilities introduced by aliased parameters.

> Also note that a lot of renaming and 'Access of discriminant-dependent 
> components is not allowed; we've tighened those rules with each version of 
> Ada.

It's not clear to me if these rules are valuable when its easy to
circumvent them.  They mostly seem to increase the complexity of the
language.

>> The difficulty I alluded lies in the answer to this question: Are
>> aliased parameters at fault, or are discriminants with defaults to
>> blame?
>
> Almost certainly discriminants with defaults, since the problem has
> existed in Ada since Ada 83, and we are not making it any worse
> (that would be impossible, IMHO).

I tend to agree.  Would it make sense to deprecate discriminants with
defaults?  As a replacement, smart pointers could be added to the
language, with syntactical overhead compared to access types, which
would allow programmers to replace discriminants with default with a
smart pointer to an unconstrained type.  Implementations would be
allowed to use reference counting, or full garbage collection.
However, they would have to ensure that references to the object held
by the smart pointer would remain live for the time any reference to
it or its components exists (an actual subprogram parameter, for
instance).  There would be no promise that cycles do not result in
memory leaks.

Run-time complexity for reference counting is less than for full
garbage collection.  Making it a language feature, rather than a
library-provided functionality, makes it easier for implementations to
optimize updating the counts.  As usual, there is a trade-off between
flexibility and overhead: if the reference counters are kept separate,
it is possible to implement weak pointers and safe references to
sub-components.  Intrusive counts provide better cache locality and
the smart pointers themselves can be a single machine word.

> Type safety is not about detering malicious programmers, merely careless 
> ones.

I think type safety is important for ending up with language semantics
that can be explained.