Safety of subprogram'unchecked_access

Safety of subprogram'unchecked_access

[dennison]

I have an arcane question about using 'access on procedures.

I have the following situation: a generic package's body instantiates another
generic package. The other generic package has a routine that takes an
"access function" parameter. The "outer" generic's body passes into that
routine the 'access of a function declared in its body. When I try to compile
the "outer" generic's body, I get an error on that call stating
"LRM:3.10.2(32), If the subprogram denoted by the prefix is declared within a
generic unit, the expected type must be declared within that same generic
unit, Continuing"

That is indeed the gist of 3.10.2(32). I can see where there could be a
problem with the generic owner of the routine going out of scope. But it
seems that 'Access would be safe in my situation. The "access function" type
is declared in a package that cannot outlive the owner of the routine who's
address is passed in.

'Unchecked_Access is not allowed for subprograms, so how do I get around
this? The only solution I can see is to change the routine into a generic
parameter to the "inner" generic. But that loses the ability to change it on
the fly. Yuk.

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Safety of subprogram'unchecked_access

[dennison]

In article <6s42l4$ll5$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

> I have the following situation: a generic package's body instantiates another
> generic package. The other generic package has a routine that takes an
> "access function" parameter. The "outer" generic's body passes into that
> routine the 'access of a function declared in its body. When I try to compile
> the "outer" generic's body, I get an error on that call stating
> "LRM:3.10.2(32), If the subprogram denoted by the prefix is declared within a
> generic unit, the expected type must be declared within that same generic
> unit, Continuing"

Oddly enough, moving the instantiation of the "inner" generic from the spec to
the body of the other generic fixed the problem. Is this the expected behavior
for Ada compilers? On the surface, you wouldn't think there'd be a difference.

--
T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Safety of subprogram'unchecked_access

[Tucker Taft]

dennison@telepath.com wrote:

: I have an arcane question about using 'access on procedures.

: I have the following situation: a generic package's body instantiates another
: generic package. The other generic package has a routine that takes an
: "access function" parameter. The "outer" generic's body passes into that
: routine the 'access of a function declared in its body. When I try to compile
: the "outer" generic's body, I get an error on that call stating
: "LRM:3.10.2(32), If the subprogram denoted by the prefix is declared within a
: generic unit, the expected type must be declared within that same generic
: unit, Continuing"

: That is indeed the gist of 3.10.2(32). I can see where there could be a
: problem with the generic owner of the routine going out of scope. But it
: seems that 'Access would be safe in my situation. The "access function" type
: is declared in a package that cannot outlive the owner of the routine who's
: address is passed in.

This restriction is not related to lifetime.  It has to do with the
possibility that subprograms declared in a generic body might require
extra "context" when called, if the implementation uses generic code
sharing.  For implementations that do strictly "macro"-like generic
code expansion, this restriction is not useful.  But portability dictated
that the restriction be independent of implementation approach.

: 'Unchecked_Access is not allowed for subprograms, so how do I get around
: this? The only solution I can see is to change the routine into a generic
: parameter to the "inner" generic. But that loses the ability to change it on
: the fly. Yuk.

You can move the instantiation of the generic, or the declaration
of the subprogram, so they are both in the spec, or both in the body.

: --
: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA