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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bbbeae4ed07e9626 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Address to function pointer conversion Date: 1997/06/13 Message-ID: <33A1831C.269F@sprintmail.com>#1/1 X-Deja-AN: 248170362 References: <5nrq5h$13cm@info4.rus.uni-stuttgart.de> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-06-13T00:00:00+00:00 List-Id: Michael Paus wrote: > > Hi, > > I just stumbled over a little problem. I have a system address and I would > like to > convert it to an access to function type. How can this be done correctly? > There is > a generic package System.Address_To_Access_Conversions which takes an > object type and then provides an access to object type and the appropriate > conversion routines from address to access type and vice versa. But, what is > the object of an access to function type here which I need to instantiate > this > package? Any suggestions are welcome. > > Michael > > PS: I currently just use an unchecked conversion which just works fine, but > that's not the answer I am looking for. Hmm, I think the answer may be that this sort of thing might just be beyond the scope of the Ada95 standard. In other words, this may be an implementation-specific (maybe even an OS-specific) thing not defined by Ada95. There may be no guaranteed portable way to take the address of a routine (I assume imported from some other language, such as C) and turn it into an access-to-subprogram. In that case, if you have an implementation specific solution that works, you may just have to live with the lack of portability. But what exactly are you trying to do? How are you acquiring this routine address? One thing people often overlook when they write bindings to other languages is the fact that it makes absolutely no difference what Ada data type you map to a given type from, e.g, C, as long as the bit representations match. In particular, there is no compelling reason a priori to favor an Ada type that provides a "lower-level" abstraction over one that provides a "higher-level" abstraction, as long as the representations match. In other words, suppose you're acquiring a function-pointer by calling some C function, such as: typedef void (*)() CallbackPtr; // arggh, is this the right syntax?? CallbackPtr getCallback (); Who says you have to map CallbackPtr to System.Address in Ada? Maybe you can map it directly into an access-to-subprogram type. If so, then you can completely avoid the System.Address middleman and the whole issue of what to convert it to: type Callback_Access_Type is access procedure; pragma Convention (C, Callback_Access_Type); -- ** is this right? function Get_Callback return Callback_Access_Type; pragma Import (C, Get_Callback, "getCallback"); ** What I don't know here is whether this Convention pragma is correct. But if it is, then this would be a guaranteed portable mechanism for doing what you want. However, the issue may be even simpler than this. Does your Ada program really need to be blind to what functions this pointer might be pointing to? In other words, does your getCallback function (or whatever) really need to be written in C? Could it be written on the Ada95 side instead? If so, then you could just statically bind to all the possible functions and not worry about a convention for Callback_Access_Type: procedure Callback_1; pragma Import (C, Callback_1, "callback1"); procedure Callback_2; pragma Import (C, Callback_2, "callback2"); ... procedure Callback_N; pragma Import (C, Callback_N, "callbackN"); type Callback_Access_Type is access procedure; function Get_Callback return Callback_Access_Type is begin -- the "..." lines below represent -- some kind of conditional structure -- (could be case, could be a bunch of ifs, whatever) ... return Callback_1'Access; ... return Callback_2'Access; ... . . . ... return Callback_N'Access; ... end Get_Callback; ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Texas Instruments Advanced C3I Systems, San Jose, CA", Work_Email => "johnv@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) "); ------------------------------------------------------------------------