Re: Address to function pointer conversion

Re: Address to function pointer conversion

[Samuel Mize]

In article <5nrq5h$13cm@info4.rus.uni-stuttgart.de>,
Michael Paus <michael@ifr16.luftfahrt.uni-stuttgart.de> wrote:
[reformatted for length]
> 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?

Depends on how you define "correctly."

There is no such conversion defined within the language, because the
language would need some way to verify that this address is the
correct place to enter a routine with the given profile.

>PS: I currently just use an unchecked conversion which just works fine,

That's the only way I can imagine.  It is NOT "incorrect", but it IS
extremely compiler-dependent.  If you port to a different platform,
compiler brand, or compiler VERSION, you'll need to re-verify that this
works right.

Sam Mize

-- 
Samuel Mize -- smize@imagin.net -- Team Ada
(personal net account)

Address to function pointer conversion

[Michael Paus]

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.

Re: Address to function pointer conversion

[John G. Volan]

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

Re: Address to function pointer conversion

[Robert A Duff]

In article <5nrq5h$13cm@info4.rus.uni-stuttgart.de>,
Michael Paus <michael@ifr16.luftfahrt.uni-stuttgart.de> wrote:
>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 ...

It doesn't work for access-to-subprograms.

Where does this address come from?  It might make sense to instead use
an access-to-subp from the start, and apply pragma Convention(C) to the
type, thus telling the compiler "represent this like the C compiler".

- Bob

Re: Address to function pointer conversion

[Robert Dewar]

Sam says

<<Depends on how you define "correctly."
 
There is no such conversion defined within the language, because the
language would need some way to verify that this address is the
correct place to enter a routine with the given profile.>>


It is worse than that. There is no guarantee at all that an access to
function value looks anything like an address. 

Indeed, on the list of future enhancements for GNAT is to replace the
current inefficient use of trampolines for pointers to nested functions
by using "fat" pointers that will have two items

1) the address of the code
2) the static link

And this is indeed probably the most sensible data structure to use for
a pointer to a function (it is what is often used in Pascal and PL/1
compilers for example).

This means that even if UC is working today in GNAT on some implementation,
it may suddenly stop working in the future.

What would be helpful is to know why you would want to do such a strange
thing ...
\x1adp

Re: Address to function pointer conversion

[Robert Dewar]

John says
~
<<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.
 >>
~
~
~
If the address is coming from C, then I think the following should be quite
portable:
~
   type x is access procedure ....
   pragma Convention (C, X);
~
   function Get_Address return x;
   pragma Import (C, Get_Address);

Now your compiler might reject the pragma Convention on X, but it is reasonable
that it shouold be supported, and if it is supported, then it should work.

Notice this general approach, instead of importing some foreign gizmo from C
like an address, import it in properly typed form, but apply pragma Convention
C to the type.

This is generally what should be done for access types as well when 
communicating with C.

Re: Address to function pointer conversion

[Robert Dewar]

Michael says

<<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.
 >>



Well, it is the only possible answer! It is clear that the language provides
no such capability, because the very *idea* of converting an address to
an access-to-function type is highly implementation dependent. What makes
you think that an access-to-function value is anything like an address?

It often is not. For example, in gcc it is often the address of a trampoline
on a local stack. In the DEC ABI, an access to function value is a pointer
to a procedure descriptor.

Unchecked conversion may work on one particular implementation, and you feel
nervous using it, because you are afraid that it might be implementation
dependent. GOOD! You should feel nervous, whatever you feel you need this
for should be reconsidered carefully, since you are venturing into the
areas of highly non-portable code.

Re: Address to function pointer conversion

[Robert Dewar]

Michael said

<<The problem which I have mentioned in my original post arises when you
want to interface an Ada program to a C function which can return pointers
to different functions like, e.g. dlsym on some UNIX systems or 
GetProcAddress
on Windows NT. These functions are essential when you want to open a
shared library (or DLL) dynamically at runtime of your program and access
functions contained in this library. Depending on the given argument (a 
string
with the name of the function) you get a void pointer to this function which 
you
just cast to the appropriate pointer type in C. So, how would you do that in
Ada? System.Address_To_Access_Conversions does not work as I have
pointed out already in my first post. An unchecked conversion may also be
problematic and is not portable. The only portable solution I see at the 
moment is
to import the dlsym function several times for each anticipated function 
pointer
type. This is not a very nice solution but I think it should work.>>



Seems a nice solution to me, and indeed is entirely the appropriate solution
in a strongly typed language!

Re: Address to function pointer conversion

[Robert A Duff]

In article <5o39sm$2fl6@info4.rus.uni-stuttgart.de>,
Michael Paus <michael@ifr16.luftfahrt.uni-stuttgart.de> wrote:
>...The only portable solution I see at the moment is to import the
>dlsym function several times for each anticipated function pointer
>type. This is not a very nice solution but I think it should work.

The above sounds reasonable, if there aren't too many different such
function prototypes.

On the other hand, if you insist on the flexibility of the
unchecked-conversion method, then it might make more sense to
unchecked-convert from one access-to-subp type to another (both types
being pragma Convention(C)).  This is more likely to be portable in
practise than unchecked-converting from type System.Address to
access-to-subp.  No guarantees, of course.

- Bob

Re: Address to function pointer conversion

[Samuel Mize]

[quotations reformatted for line length]

Robert Dewar wrote:
> 
> Michael said
> 
> <<The problem which I have mentioned in my original post arises
> when you want to interface an Ada program to a C function which
> can return pointers to different functions ...
...
> [unchecked conversion] may also be problematic and is not
> portable. The only portable solution I see at the moment is to
> import the dlsym function several times for each anticipated
> function pointer type. This is not a very nice solution but I
> think it should work.>>
> 
> Seems a nice solution to me, and indeed is entirely the
> appropriate solution in a strongly typed language!

I would agree EXCEPT -- dlsym is returning an address at run time,
so you can't use pragma Import.  You still have the problem, how
do you call this address from Ada?

It seems to me that you need a C function that takes an address
and calls the function at that address.  You can then pragma
Import that function.  If they're all "void FUNCTION (void)"
this could be one C function.  If they have different profiles,
you would have several C interface functions with parameters,
that call the function at "address" with the same parameters.

Am I missing something simpler?

Sam Mize

--
-- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: Address to function pointer conversion

[Robert A Duff]

In article <33A5B0B3.7EA663D3@link.com>, Samuel Mize  <smize@link.com> wrote:
>I would agree EXCEPT -- dlsym is returning an address at run time,
>so you can't use pragma Import.  You still have the problem, how
>do you call this address from Ada?

True, but you can use pragma Convention(C) on the access-to-function
type.  Anyway, the caller needs to know what arguments to pass, so it's
expecting some particular argument profile.  So the caller, at least,
ought to know what to do.

- Bob

Re: Address to function pointer conversion

[Michael Paus]

The problem which I have mentioned in my original post arises when you
want to interface an Ada program to a C function which can return pointers
to different functions like, e.g. dlsym on some UNIX systems or 
GetProcAddress
on Windows NT. These functions are essential when you want to open a
shared library (or DLL) dynamically at runtime of your program and access
functions contained in this library. Depending on the given argument (a 
string
with the name of the function) you get a void pointer to this function which 
you
just cast to the appropriate pointer type in C. So, how would you do that in
Ada? System.Address_To_Access_Conversions does not work as I have
pointed out already in my first post. An unchecked conversion may also be
problematic and is not portable. The only portable solution I see at the 
moment is
to import the dlsym function several times for each anticipated function 
pointer
type. This is not a very nice solution but I think it should work.

Any comments are welcome.

Michael

Re: Address to function pointer conversion

[John G. Volan]

Robert Dewar wrote (quoting me):
> 
> John says
> ~
> <<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.
>  >>

Later on in this same post which Robert quoted, I suggested:

>   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.

In his reply, Robert wrote:

> If the address is coming from C, then I think the following should be quite
> portable:
> 
>    type x is access procedure ....
>    pragma Convention (C, X);
> 
>    function Get_Address return x;
>    pragma Import (C, Get_Address);

Excellent!  Looks just like what I wrote.

> Now your compiler might reject the pragma Convention on X, but it is reasonable
> that it shouold be supported, and if it is supported, then it should work.
> 
> Notice this general approach, instead of importing some foreign gizmo from C
> like an address, import it in properly typed form, but apply pragma Convention
> C to the type.
> 
> This is generally what should be done for access types as well when
> communicating with C.

Thank you Robert, that answers my question.  I didn't know whether this
pragma was available for access-to-subprogram types.  (I was making an
informed guess.)
 
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@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? :-) ");
------------------------------------------------------------------------

Re: Address to function pointer conversion

[Robert Dewar]

Sam says

<<I would agree EXCEPT -- dlsym is returning an address at run time,
so you can't use pragma Import.  You still have the problem, how
do you call this address from Ada?>>

No, on the Ada side the function which of course you Import (I don't understand
your comment about not being able to use Import), returns an access to
procedure value NOT an address.

Re: Address to function pointer conversion

[Samuel Mize]

Robert Dewar wrote:
> 
> Sam says
> 
> <<I would agree EXCEPT -- dlsym is returning an address at run time,
> so you can't use pragma Import.  You still have the problem, how
> do you call this address from Ada?>>
> 
> No, on the Ada side the function which of course you Import (I don't
> understand your comment about not being able to use Import), returns
> an access to procedure value NOT an address.

I think I have put it together from several messages:

- You specify one or more access-to-function types, with
  Convention(C).  This way, whatever C uses as a pointer to a
  function -- in this case, an address -- can be called by
  Ada.  This is what I didn't see how to do, but someone else
  pointed it out.

- You import dlsym, which returns a pointer-to-function (an
  address).  You possibly do this several times if you expect
  it to return functions with different profiles.

Then you can call dlsym, and call what it returns.

Sam Mize

--
-- Samuel Mize    (817) 619-8622    smize@link.com    "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: Address to function pointer conversion

[Robert Dewar]

Sam says

<<- You import dlsym, which returns a pointer-to-function (an
  address).  You possibly do this several times if you expect
  it to return functions with different profiles.
 
Then you can call dlsym, and call what it returns.>>


Be sure to use pragma Convention C *on the function types involved*, not
just on the subprograms themselves.

Re: Address to function pointer conversion

[Robert Dewar]

John said

<<Thank you Robert, that answers my question.  I didn't know whether this
pragma was available for access-to-subprogram types.  (I was making an
informed guess.)
 >>

It is obviously not *required* to be available, but it likely will work fine.
If it is rejected, this is a red flag that the interface will not work.

Re: Address to function pointer conversion

[Robert Dewar]

And Sam, do NOT assume that C represents a pointer to a function as an
address, there is no such requirement in C.

Re: Address to function pointer conversion

[Robert Dewar]

Matthew Heaney asks

<<I'm confused by this answer.  Do you mean

If it is accepted, then it is guaranteed to work.

or do you mean

If it is accepted, it is not guaranteed to work, but is still likely to
work anyway.

When you say "but it will likely will work fine," are you describing the
case when the pragma is accepted?  Or that "it will likely work fine" even
if the pragma isn't accepted?

I'm confused because if the pragma is accepted, "likely is work fine" isn't
how I would like to see it described.  I'd rather you say, "If the pragma
is accepted, then it is guaranteed to work."  Having something compile
without error, and then describing that program as "likely to work" doesn't
give one a high degree of confidence, n'est-ce pas?
>>

Robert replies

The trouble is that "works" here is not well defined, it depends on exactly
what you are doing, for example, if the C program you call raises a signal,
what happens? Not clear. So likely to work is indeed a reasonable way of
saying, on an informal basis, that, based on a best guess of what you
might expect to work, it will work. Other things that might cause trouble
are varargs for example. 

Re: Address to function pointer conversion

[Matthew Heaney]

In article <dewar.866852244@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

><<Thank you Robert, that answers my question.  I didn't know whether this
>pragma was available for access-to-subprogram types.  (I was making an
>informed guess.)
> >>
>
>It is obviously not *required* to be available, but it likely will work fine.
>If it is rejected, this is a red flag that the interface will not work.

I'm confused by this answer.  Do you mean

If it is accepted, then it is guaranteed to work.

or do you mean

If it is accepted, it is not guaranteed to work, but is still likely to
work anyway.

When you say "but it will likely will work fine," are you describing the
case when the pragma is accepted?  Or that "it will likely work fine" even
if the pragma isn't accepted?

I'm confused because if the pragma is accepted, "likely is work fine" isn't
how I would like to see it described.  I'd rather you say, "If the pragma
is accepted, then it is guaranteed to work."  Having something compile
without error, and then describing that program as "likely to work" doesn't
give one a high degree of confidence, n'est-ce pas?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Address to function pointer conversion

[Michael Paus]

In <dewar.867185277@merv> Robert Dewar wrote:
> Matthew Heaney asks
> 
> <<I'm confused by this answer.  Do you mean
> 
> If it is accepted, then it is guaranteed to work.
> 
> or do you mean
> 
> Robert replies
> 
> The trouble is that "works" here is not well defined, it depends on exactly
> what you are doing, for example, if the C program you call raises a signal,
> what happens? Not clear. So likely to work is indeed a reasonable way of
> saying, on an informal basis, that, based on a best guess of what you
> might expect to work, it will work. Other things that might cause trouble
> are varargs for example. 
> 

So, what you say here is that if the pragma is accepted the program is
guaranteed to work exactly as reliable as any other program which
directly interfaces to some C function because the potential problems
you have mentioned will always make an Ada program which interfaces
to a foreign language somewhat less reliable than a pure Ada program.

I think everybody knows this and nobody will expect more.

Michael