comp.lang.ada
 help / color / mirror / Atom feed
From: "John G. Volan" <johnvolan@sprintmail.com>
Subject: Re: Address to function pointer conversion
Date: 1997/06/13
Date: 1997-06-13T00:00:00+00:00	[thread overview]
Message-ID: <33A1831C.269F@sprintmail.com> (raw)
In-Reply-To: 5nrq5h$13cm@info4.rus.uni-stuttgart.de


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? :-) ");
------------------------------------------------------------------------




  reply	other threads:[~1997-06-13  0:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-06-13  0:00 Address to function pointer conversion Michael Paus
1997-06-13  0:00 ` John G. Volan [this message]
1997-06-14  0:00   ` Robert Dewar
1997-06-17  0:00     ` John G. Volan
1997-06-20  0:00       ` Robert Dewar
1997-06-24  0:00         ` Matthew Heaney
1997-06-24  0:00           ` Robert Dewar
1997-06-25  0:00             ` Michael Paus
1997-06-13  0:00 ` Samuel Mize
1997-06-14  0:00   ` Robert Dewar
1997-06-14  0:00 ` Robert A Duff
1997-06-14  0:00 ` Robert Dewar
1997-06-16  0:00   ` Michael Paus
1997-06-16  0:00     ` Robert A Duff
1997-06-16  0:00     ` Robert Dewar
1997-06-16  0:00       ` Samuel Mize
1997-06-16  0:00         ` Robert A Duff
1997-06-17  0:00         ` Robert Dewar
1997-06-17  0:00           ` Samuel Mize
1997-06-20  0:00             ` Robert Dewar
1997-06-20  0:00             ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox