Re: Run-Time Type Assignment

["Ben Brosgol" <brosgol@world.std.com>]

> > The reason it is safe to pass nested subprograms as parameters in Pascal
is
> > that Pascal does not allow subprograms to be used as values for
variables or
> > placed in data structures.  GNAT's 'Unrestricted_Access is just as safe,
> > provided that you abide by the Pascal restrictions.
>
> Yeah, and array indexing in C is just as safe as in Ada -- so long as
> you don't index outside the array bounds.  Driving 120 miles per hour
> in a 30 mph zone without wearing a seat belt is perfectly safe -- so
> long as you don't cause a collision.
>
> OK, sorry for infamatory rhetoric, Ben, but claiming that
> 'Unrestricted_Access is as safe as in Pascal is just plain silly.
> The fact is, you can accidentally create dangling pointers using
> 'Unrestricted_Access, which you can't do by passing procedural
> parameters in Pascal.

Hmm, I try not to say too many silly things (unless I flag them with
smileys) so I guess I need to give some additional explanation for my
comment.

First, I was not claiming that 'Unrestricted_Access is a completely safe
construct.  Obviously you can create dangling references.

But lots of programs have no need for the generality of stuffing a (pointer
to a) subprogram in a data structure, or assigning it to a variable; they
only need to pass subprograms as run-time parameters.  For such programs it
will be perfectly safe to use 'Unrestricted_Access to pass a nested
subprogram as a parameter; there is no danger of dangling references, and
you still get the other checks that 'Access entails.  (Phrased differently:
the context of the original discussion was whether anything that could be
done in Pascal could be done in Ada.  So if you have a Pascal program that
passes a procedure or function as a parameter, and then convert the program
to Ada, there is no lack of safety in using Unrestricted_Access.)  I see
this as different from the array indexing case.  It is hard, if all you want
to do is pass a subprogram as a parameter, to accidentally store it into a
data structure.  It is easy to make a programming error and accidentally
have an array index out of bounds.

> >...(I.e.,
> > Unrestricted_Access still entails the other checks required by the
language;
> > e.g. static subtype conformance for corresponding formals, matching
> > conventions.)  For example:

> Well, it's nice that it detects *some* errors (it detects misspellings
> like 'Unrestricted_Acess, too!), but it doesn't detect dangling
> pointers.

It's not clear when to do the detection (see below).

> >   declare
> >     procedure Q is begin null; end Q;
> >   begin
> >     Ref := Q'Unrestricted_Access; -- OK
>
> That's the problem (the above "OK").  If you call Ref.all later, you're
> in trouble.  GNAT thinks it's OK, but it is *not* OK.

Might or might not be OK; depends on your definition of "later".  You're OK
if the call is only from the block that declares Q.  (And you're probably
still OK even if the call is from an outer scope, if (as is the case here) Q
does not make any up-level references to stack variables.)

But the point is not that Unrestricted_Access can lead to dangling
references.  It's that you still get the checks as for 'Access except for
scope accessibility, and that you don't need that check if you are only
passing a subprogram as a parameter and not assigning it to a variable.

-Ben