[OT: C] Getting pointers to functions

[syphilis]

Hi,

I'm wanting to get pointers to various mpfr library functions (because I want to provide a perl wrapping for an mpfr function that takes a "pointer to function" as one of its arguments). The following demo works fine, in so far as it goes:

use strict;
use warnings;


use Inline C => Config =>
  LIBS => '-lmpfr -lgmp',
  BUILD_NOISY => 1;

use Inline C => <<'EOC';

#include <mpfr.h>

#define FUNC_PTR(x) newSViv(PTR2IV(x))

SV* get_mpfr_mul_func_ptr() {
    return newSViv(PTR2IV(mpfr_mul));
}

SV * get_mpfr_add_func_ptr() {
    return newSViv(PTR2IV(mpfr_add));
}

EOC

print get_mpfr_mul_func_ptr(),  "\n";
print get_mpfr_add_func_ptr(),  "\n";

That gives me the numeric values of pointers to the mpfr_mul and mpfr_add functions, and I can readily construct the pointers to those functions from that info.

But the problem is that there's maybe 200 mpfr functions for which I would need to create pointers - and I'm not so sure that writing separate XSubs for each of those functions is the best way to proceed.
What would be good is to have a generic function that takes the name of the mpfr function as its argument, and then returns the pointer value of that mpfr function.
Something like:

SV * get_func_ptr(char * func_name) {
   /* code that returns the pointer
    value for the requested function */
}

But I don't know of any tricks that would allow that to happen.
What's the best approach here ... a C lookup table ?

Cheers,
Rob

[Corion]

Why not be explicit and create the XS using Perl from the C header files? That way, you also avoid the problem of having different (C) signatures of the functions.

Doing that stuff explicitly allows you to more easily exclude functions that have special signatures from your generic approach later on.

[syphilis]

Why not be explicit and create the XS using Perl from the C header files?

IIUC, the suggestion here is to avoid passing pointers to functions around - which I think is generally good advice, but not applicable for this case (AFAICT).

S you've also pointed out, the presence of different/special signatures is also an issue - but I think I can handle that acceptably by accommodating only those functions that take only mpfr_t arguments.
(Hmmm ... except that I'll have to allow mpfr_strtofr which takes a "string" argument.)
The real annoyance is not having simpler access to the function pointers.

This is not a critical mission - but it's a bit interesting, and is taking me into areas of C that I've not visited before.
I'll continue to play with it. Below my sig is a working example of where I've got to so far - but it requires Math::MPFR, a recent svn version of the mpfr library and a C99 compiler.

Cheers,
Rob
Read more... (7 kB)

[BrowserUk]

Assuming that all the functions you're trying to get the addresses of are exported from a dll, you could use GetProcAddress() to look them up.

Two possible problems:

1. It's a windows-only function, though I would think that *nix would have something similar.
2. The names required are those exported, which is (mostly) okay for C code, but can be horribly mangled for C++.

[syphilis]

...you could use GetProcAddress() to look them up

Good point - I hadn't thought of that largely because I'm using static libraries.
Although I habitually use static libraries, there's no real need for me to avoid using dynamic mpfr and gmp libraries.

Cheers,
Rob

[RonW]

because I want to provide a perl wrapping for an mpfr function that takes a "pointer to function" as one of its arguments

Usually, the reason for passing a function pointer to another function is so the called function can either call the other function, or set up a call-back so something else (like an event handler) can call it.

That means you need to provide an address that is "local" to the function you are passing the pointer to.

With static linking, your XSubs will be in the same address space as the functions you want pointers to.

With dynamic linking, the addresses your Xsub will have will be "mapped" addresses. That is, addresses in the XSub's address space that it can use to call the functions in the DLL's address space.

I would suggest creating a C array of function pointers initialized to the addresses of the functions you need pointers for:

funcp FuncArray[] = {
    mpfr_mul,
    mpfr_read,
    /* etc */
}

Then your XSub can fetch the needed pointer by index.

To avoid having to figure out the indexes, you can use Perl to read the C source of FuncArray and create a hash with the function names as keys and indexes as values.

[syphilis]

I would suggest creating a C array of function pointers initialized to the addresses of the functions ...

Yes, I think that would have been a good starting point if I had stayed with my original intention.
However, in a subsequent discussion on the mpfr mailing list it was suggested that the best approach would be to rewrite mpfr_round_nearest_away() in perl, rather than wrapping it.
(This avoids the C99 requirement, avoids having to accommodate different C function prototypes and further allows the user to obtain "round to nearest, ties away from zero" for functions that the user might create.)

So I'm going with that approach. It's only a few lines of code and instead of using pointers to the mpfr library functions, it uses code references to the XS subs that wrap those mpfr library functions.

Calling it will be as simple as rndna(\&Rmpfr_foo, $rop, @args) where @args are the input args appropriate for the function Rmpfr_foo.

So there was a strong element of "XY problem" after all - largely due to the damned blinkers I habitually like to wear.

Cheers,
Rob