From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,99ab4bb580fc34cd
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Q: access to subprogram
Date: 1996/07/02
Message-ID: <Dtxu2p.97F@world.std.com>#1/1
X-Deja-AN: 163367575
references: <4rb9dp$qe6@news1.delphi.com>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-07-02T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <4rb9dp$qe6@news1.delphi.com>,  <tmoran@bix.com> wrote:
>Could someone please explain
>  "subprogram must not be deeper than access type".

Here, "deeper" means more nested within a subprogram or block_stm or
task_body.  Nested within a subprogram is the usual problem.

>I want package utilities to offer
>  type p is access procedure(x:in integer);
>and
>  procedure do_stuff(how : in p);
>
>But if my main program 'with utilities' and
>  procedure this_is_how(x:in integer);
>..
>  utilities.do_stuff(this_is_how'access);

Right, that's illegal.  You need to put This_Is_How in a library
package; then it will work.  The main subprogram is a subprogram, and
therefore represents a deeper level of nesting.  You can't take 'Access
of something *inside* a subprogram, and let that pointer value live
outside the subprogram.  Note that Ada tasks can keep running long after
the main subprogram is done.

>I get that message from GNAT 3.04 for DOS.  I also note the same problem
>prevents compilation of the PMV16 OS/2 bindings, and is gotten around
>in the new OS/2 bindings with "this_is_how'unrestricted_access", which
>I don't see in the LRM.  The message indicates an understandable
>problem, but what's the workaround to allow my package utilities to
>offer a do_stuff procedure.

The Unrestricted_Access attribute is indeed not part of the Ada
language.  It is a GNAT-specific extension.  I've used it some in my own
code, I must admit.  It's dangerous, in the sense that if you leave the
scope containing This_Is_How, and then call through the pointer, you
will get nonsense.

During the design of Ada 9X, we proposed a SAFE way of taking 'Access of
more-deeply-nesting subprograms.  To this day, I remain astonished and
sad that this particular feature didn't make it into Ada 95.  After
all, even Pascal has that feature!  And GNU C, which allows nested
functions (unlike standard C) allows this feature.

The work-around is to use generics.  Pass in This_Is_How as an actual to
a generic formal procedure.  This is verbose, and doesn't allow
recursion.  Alternatively, bully your favorite Ada compiler vendor to
support 'Unrestricted_Access.  This is sad, since 'Unrestricted_Access
is inherently unsafe, whereas we know how to provide the same
functionality safely.  Sigh.

Note also that 'Unrestricted_Access on objects is even less safe -- it
can produce a totally meaningless pointer from the start.  I would much
prefer if GNAT had separated these two things into two separate
features.

- Bob