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,60338dc6410fd6ce X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: Safety of subprogram'unchecked_access Date: 1998/08/27 Message-ID: #1/1 X-Deja-AN: 385421778 Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.camb.inmet.com References: <6s42l4$ll5$1@nnrp1.dejanews.com> Organization: Intermetrics, Inc. Newsgroups: comp.lang.ada Date: 1998-08-27T00:00:00+00:00 List-Id: 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