Re: Preventing Unchecked_Deallocation?

["Randy Brukardt" <randy@rrsoftware.com>]

"Simon Belmont" <sbelmont700@gmail.com> wrote in message 
news:26e4f2a4-edae-4e37-8697-f2390e636a21@z31g2000vbt.googlegroups.com...

>I agree with all your points, and was essentially looking for a way to
>enforce this at compile time.

One way to do this is to use the Restriction (No_Dependence => 
Unchecked_Deallocation), but that of course will prevent anyone from using 
it, which might be going too far. (But not if you are using Ada 2012 
subpools for storage management.)

>  I have casually looked at the implicit
> dereferencing in 2012, but from a once-over it seems like it can only
> be for visible parts (i.e. access discriminents); the problem is that
> the implicit dereference doesn't stop you from explicit dereference,
> and you can then cast away any sort of anonymity, constness, or not-
> nullness.

The entire point is that you can (at least potentially) write the 
dereference. But what you can't do is assign the access discriminant to most 
other access types, because the accessibility check will fail. It can only 
be assigned to some type that will live less long than the object with the 
access discriminant (which usually will be *very* short-lived).

If you don't need (visible) dereferences at all, you should definitely use a 
handle type like the Cursor type of Ada Containers. Indeed, I think that the 
vast majority of the time, you should simply use the Cursor type directly 
(putting the objects into appropriate instances of the containers). There 
you don't have any visible access types (and any existence of them is easily 
detected with tools, see below).

As for the concern about using Unchecked_Deallocation on a local access 
type: it's always bad practice to deallocate something for a type other than 
the one it was allocated for. And, sure, the compiler can't detect this. But 
this is just one out of dozens of ways that a malicious programmer could 
damage your application. There is no way that Ada could possibly prevent 
them all without becoming far too restrictive to be able to accomplish 
anything. (Example: SPARK.)

There is always an important role to play for the culture and/or management 
of an organization. Both the culture and rules (enforced with external tools 
like AdaControl) should minimize the possibility of rouge programmers. But 
no one can prevent intentional maliciousness; at best you can only minimize 
it.

It probably was a mistake to allow allocations for general access types (and 
by definition, if there were no allocations, there could be no 
DEallocations). [It is best is allocations are done for a pool-specific type 
and converted to the general access type as needed.] But it's way too late 
to change that now, it surely would break many existing Ada 95 programs.

> It would seem that if everyone is in agreement that doing
>something is bad practice and should be avoided the language ought to
>have a way to prevent it, but I suppose when you start in with
>Unchecked_Anything, the results are by definition unpredictable.

Exactly.

>If I were king of Ada, i would just cut through the tricks and add a
>new 'reference' type; basically just syntactical sugar for a constant,
>not null, auto-dereferenced, optionally limited access type.  It would
>cut down on errors, simplify the syntax, and even present room for
>compile-time optimizations.  It's strange to me that a language of
>such a high level of abstraction when it comes to everything else
>still regards access types with the underlying 'address stored in
>memory' mentality.

We looked at the possibility for Ada 2012, but adding a new kind of access 
type that was "just a little bit different" than the existing ones did not 
look very appealing. Part of the problem is a completely new kind of type 
cannot do anything to make Ada simpler, because all of the old kinds of 
types are still there and still needed. (It's not like you can replace 
allocations with a "ref" type that doesn't support allocations, and 
allocations are still going to be needed.)

[Also, the sort of type you define is essentially a standard private type --  
we surely don't need a new language feature for that! It's only interesting 
if it has some access-like behavior.]

Another problem is that a "limited" access type (another idea we looked at) 
would be something totally new: there are no elementary limited types in Ada 
today. (A limited private type completed with an elementary type is still 
considered composite.) For instance, an immutably limited type (which this 
probably would be) is always passed by reference, something we clearly don't 
want for a reference type.

So we'd be looking at major surgury to the language, and no major benefit. 
Moreover, when we studied the needed accessibility rules, it turned out that 
they were essentially identical to the ones for access discriminants. Thus 
we decided to just add some "sugar" to make access discriminants usable, 
rather than adding a new type.

                                               Randy.