Re: Preventing Unchecked_Deallocation?

[Simon Belmont <sbelmont700@gmail.com>]

On Feb 6, 11:21 am, Adam Beneschan <a...@irvine.com> wrote:
> On Feb 5, 8:42 am, Simon Belmont <sbelmont...@gmail.com> wrote:
>
> > On Feb 4, 9:40 am, AdaMagica <christ-usch.gr...@t-online.de> wrote:
>
> > > Don't understand your problem. However, keep in mind that UD with a
> > > type different from the one with which the objects were allocated is
> > > erroneous.
>
> > When you say erroneous, do you mean forbidden by the language (i.e. an
> > exception) or that it will cause undefined operation?  My concern is
> > that if a unit exposes an access value to other units, any of them may
> > use UD to delete the object at any time.  Obviously this sort of
> > behavior would cause the program to quickly crash due to a null
> > pointer, but all things being equal I would prefer a compile-time
> > mechanism to prevent the UD outright.
>
> I think the solution is not to expose the access type, but have your
> package define a private type.  Ada 2012 is supposed to have new
> mechanisms that allow packages to define "dereference" operations that
> could allow package users to use the same kind of syntax on objects of
> private types that they can use on access types.  If you do this, then
> it's likely that the package that defines the type can control what
> operations are available and not make Unchecked_Deallocation
> available.  However, I haven't yet studied the new feature so I can't
> say for sure.
>
> As a general rule, though, I believe that if a package does make an
> access type visible, users of the package should not try to deallocate
> any objects of the type themselves, when objects of the type are
> supplied by the package.  Instead, the package should provide
> operations to do any needed deallocations (ideally not a "Deallocate"
> operation, but perhaps a "No Longer Needed" operation so that it's the
> package that defines the type that decides when it's OK to
> deallocate).  I don't think the language can prevent package users
> from deallocating, except by using private types.  But I'd say that
> doing your own Unchecked_Deallocation on an object allocated by
> another package (if the documentation doesn't explicitly say it's OK)
> is just poor programming, and there's a limit to how much Ada can do
> to prevent poor programmers using Unchecked routines from doing
> damage.  (Even if you used private types, Ada can't prevent a user
> from using Unchecked_Conversion to convert to an access type and then
> deallocating it.  And I think I've known some programmers who wouldn't
> see anything wrong with doing that, if they believed it would solve
> their problem.)
>
> Conceivably, it might be possible to add a "not deallocatable" aspect
> to an access type and add language rules to Unchecked_Deallocation and
> to the rules on type conversions so that this could be prevent.
> However, since the language seems to have been moving in the direction
> of making it simpler not to have visible access types at all, I doubt
> that ARG would deem worthwhile to add this kind of feature.
>
>                                 -- Adam

I agree with all your points, and was essentially looking for a way to
enforce this at compile time.  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.  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.

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.

Thank you again

-sb