a "general function signature" pointer that points to an arbitrary function

I'll try to explain better what I want to do. I read a file with function signatures, and I want to create a pointer to each function.

For example, a file that looks like this:

something.dll;int  f(char* x, int y, SOMESTRUCT z)
something.dll;void g(void)
something.dll;SOMESTRUCT l(longlong w)

now, during runtime I want be able to create pointers to these functions (by loading something.dll and using GetProcAddress to these functions).

Now, GetProcAddress returns 开发者_StackOverflowFARPROC which points to an arbitrary functions, but how can I use FARPROC to call these functions during runtime? From what I know, I need to cast FARPROC to the correct signature, but I can't do it during runtime (or at least I don't know how).

Does anyone have any idea how to design do that?

Thanks! :-)

---

1. Function types are compile-time in C++, so it won't work, unless you can define all the types you're going to use in advance.

2. Its a matter of pushing the arguments to the stack (and local vars are like that) and calling the function as void (__cdecl *)(void).

3. With some other kinds of functions (like fastcall, or thiscall) it can be more problematic.

Update: I actually made an example, and it works on codepad: (Also works with stdcall functions, because of stack restore after aligned stack alloc)

http://codepad.org/0cf0YFRH

#include <stdio.h>

#ifdef __GNUC__
 #define NOINLINE __attribute__((noinline))
 #define ALIGN(n) __attribute__((aligned(n)))
#else
 #define NOINLINE __declspec(noinline)
 #define ALIGN(n) __declspec(align(n))
#endif

//#define __cdecl

// Have to be declared __cdecl when its available, 
// because some args may be passed in registers otherwise (optimization!)
void __cdecl test( int a, void* b ) {
  printf( "a=%08X b=%08X\n", a, unsigned(b) );
}

// actual pointer type to use for function calls
typedef int (__cdecl *pfunc)( void );

// wrapper type to get around codepad's "ISO C++" ideas and gcc being too smart
union funcwrap { 
  volatile void* y; 
  volatile pfunc f; 
  void (__cdecl *z)(int, void*);
};

// gcc optimization workaround - can't allow it to know the value at compile time
volatile void* tmp = (void*)printf("\n");
volatile funcwrap x; 
int r;

// noinline function to force the compiler to allocate stuff 
// on stack just before the function call
NOINLINE
void call(void) {
  // force the runtime stack pointer calculation
  // (compiler can't align a function stack in compile time)
  // otherwise, again, it gets optimized too hard

  // the number of arguments; can be probably done with alloca()
  ALIGN(32) volatile int a[2]; 
  a[0] = 1; a[1] = 2; // set the argument values
  tmp = a; // tell compiler to not optimize away the array
  r = x.f(); // call the function; returned value is passed in a register

  // this function can't use any other local vars, because
  // compiler might mess up the order
}

int main( void ) {
  // again, weird stuff to confuse compiler, so that it won't discard stuff
  x.z = test; tmp=x.y; x.y=tmp;
  // call the function via "test" pointer
  call();
  // print the return value (although it didn't have one)
  printf( "r=%i\n", r );
}

---

Once you have a FARPROC, you can cast the FARPROC into a pointer to the appropriate function type. For example, you could say

int (*fPtr)(char*, int, SOMESTRUCT) = (int (*)(char*, int, SOMESTRUCT))GetProcAddress("f");

Or, if you want to use typedefs to make this easier:

typedef int (*FType)(char *, int, SOMESTRUCT);
FType fPtr = (FType)GetProcAddress("f");

Now that you have the function pointer stored in a function pointer of the appropriate type, you can call f by writing

fPtr("My string!", 137, someStructInstance);

Hope this helps!

---

The compiler needs to know the exact function signature in order to create the proper setup and teardown for the call. There's no easy way to fake it - every signature you read from the file will need a corresponding compile-time signature to match against.

You might be able to do what you want with intimate knowledge of your compiler and some assembler, but I'd recommend against it.