21

I have the need to dynamically link against a library at run-time and resolve a series of functions using dlsym. My first thought was to use an array of function pointers that can be easily iterated through by leveraging a secondary array of char * representing the symbol names.

However, the problem with this is that not all of the functions take the same arguments. Is there a way to use a generic function pointer in the array, but assign it to a more restrictive function pointer prototype? For example:

If I need to resolve these functions:

int (*functionA)(int)
char (*functionB)(char,int)

Is it possible to do something like (pseudo-ish .. )

void* functionList(...)[2] = {functionA, functionB};

Along with

char FuncNameA[] = "functionA";
char FuncNameB[] = "functionB";
char *functionNames[2] = {FuncNameA, FuncNameB};

For the purpose of looping though the call to dlsym for symbol resolution

int i = 0;
for(; i<2; i++)
    functionList[i] = dlsym(DL_OPEN_HANDLE, functionNames[i]);

Where DL_OPEN_HANDLE would be defined by an earlier call to dlopen.

sigjuice
  • 28,661
  • 12
  • 68
  • 93
sherrellbc
  • 4,650
  • 9
  • 48
  • 77
  • @edtheprogrammerguy, I have no idea. If it were possible I figured it would be something like `void* (*func)(void*, ...)` , or similar. – sherrellbc Jul 17 '15 at 18:47
  • 2
    @edtheprogrammerguy: `void*` is likely to work, but not guaranteed by the C standard. All *object* pointer types can be converted to `void*` and back again without loss of information, but there's no such guarantee for converting function pointer types to `void*`. – Keith Thompson Jul 17 '15 at 18:51
  • 1
    It is a very delicate area. The POSIX spec was changed relatively recently. See [0000074: Pointer types problem](http://austingroupbugs.net/view.php?id=74) for POSIX's view on the situation. – Jonathan Leffler Jul 17 '15 at 18:57
  • Related question: [Why are function pointers and data pointers incompatible in C/C++?](http://stackoverflow.com/questions/12358843/why-are-function-pointers-and-data-pointers-incompatible-in-c-c). – sleske Sep 15 '15 at 13:04

3 Answers3

25

The C standard guarantees that any object pointer type can be converted to void* and back again without loss of information (meaning that the re-converted pointer will compare equal to the original one).

There is a different guarantee for function pointers: Any function pointer can be converted to any other function pointer type and back again without loss of information.

(There is no guarantee regarding conversions between function pointers and object pointers, or more specifically between function pointers and void*. An implementation could, for example, make void* 64 bits and function pointers 128 bits.)

You can use, for example, void(*)(void) as a generic function pointer type:

typedef void (*funcptr)(void);

You must convert back to the original pointer type before executing a call to avoid undefined behavior.

On the other hand, you're using dlsym(), which returns a void*. My understanding is that POSIX guarantees that the void* returned by dlsym() (if the name argument names a function) can be converted to a function pointer, which can be used to call the function. If the only functions you care about are those whose addresses are returned by dlsym(), then you can use void*.

(POSIX previously guaranteed, as an extension to the C standard, that a function pointer can be converted to void* and back again. That guarantee was later dropped. Thanks to Jonathan Leffler for pointing this out.)

In any case, using function pointers to store the addresses of functions probably makes for clearer code.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • 2
    Sadly, although it used to, it doesn't any more. Section [2.12.3](http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_12) provided that guarantee up to POSIX 1003.1:2008, but the revision POSIX 1003.1:2013 removed that subsection. See also [0000074: Pointer Types Problem](http://austingroupbugs.net/view.php?id=74) — also mentioned in a comment to the question — for the details. Frankly, I'm not sure that what we've got now is better than what we had before. – Jonathan Leffler Jul 17 '15 at 19:07
  • 1
    @JonathanLeffler: So POSIX still guarantees that a `void*` returned by `dlsym()` can be converted to a function pointer (if the `name` argument names a function), but does not guarantee that an arbitrary function pointer can be converted to `void*` and back again; is that correct? – Keith Thompson Jul 17 '15 at 19:11
  • 1
    AFAICT, yes. Which is pretty damn weird, but … who said standards had to be rational? – Jonathan Leffler Jul 17 '15 at 19:12
  • 1
    Good answer. I'll +1 if you put "any function pointer can be converted to any other function pointer type and back again without loss of information" **first**, and only **then** say that there is no guarantee that a function pointer can be converted into a `void *` and back. Remember - answers are "cognition funnels", but some people are in a hurry, skimming, or are just bad at reading, so you want to help move the minds of readers towards the answer as quickly and clearly as possible, and then elaborate after that. – mtraceur Jan 21 '20 at 20:48
  • @KeithThompson Cool, thanks. I was imagining pulling "Any function pointer can be converted to any other function pointer type ..." up to be the very first sentence of the whole answer, and then transitioning into what you said about `void*` with something like "Not to be confused with the similar guarantee about `void*`, which only applies to object pointer types. An implementation could, for example, make `void*` 64 bits and function pointers 128 bits." But this is already an improvement, so +1. – mtraceur Jan 21 '20 at 22:36
  • I'm thinking it would be legal to type pun `union { void *obj; void (*func)(void) }` if you need generics across both data and functions. – Samuel Danielson Oct 14 '21 at 15:54
5

You should probably define your list as void *functionList[2], since dlsym returns a void *. Once you know which function you have, you can cast it to the proper type.

void *functionList[2];

...

int (*functionA)(int) = (int(*)(int))functionList[0];
char (*functionB)(char,int) = (char(*)(char, int))functionList[1];
dbush
  • 205,898
  • 23
  • 218
  • 273
5

dlsym returns a data pointer of type void *, but POSIX guarantees that this can be cast to a function pointer of the appropriate type:

Implementations supporting the XSI extension [...] require that an object of type void * can hold a pointer to a function. The result of converting a pointer to a function into a pointer to another data type (except void *) is still undefined, however.

Since Version 7 of POSIX, all implementations (not just XSI) are required to support the conversion.

Because conversion from a void * pointer to a function pointer via a direct cast can result in compiler warnings, older versions of POSIX recommend performing the conversion via aliasing:

int (*fptr)(int);
*(void **)(&fptr) = dlsym(handle, "my_function");

In the current version the recommendation is changed to:

int (*fptr)(int);
fptr = (int (*)(int))dlsym(handle, "my_function");
ecatmur
  • 152,476
  • 27
  • 293
  • 366
  • 1
    Geez, that former syntax is ugly. The latter syntax is actually readable; I have no idea how to interpret the former. – sherrellbc Jul 17 '15 at 19:03
  • @sherrellbc it's aliasing `fptr` with a `void*` pointer by casting a pointer to `fptr` to a pointer to pointer to void, dereferencing it, and then assigning to the result. As you say, it's ugly; you may see it in even relatively recent code, though. – ecatmur Jul 17 '15 at 19:04