Is there any way to get a pointer to the current function, maybe through gcc extensions or some other trickery?
Edit I'm curious whether it is possible to get the function pointer without ever explicitly using the function's name. I thought I had a good reason for wanting this, realized that I didn't really, but am still curious if it is possible.
This isn't especially portable, but should work on at least some platforms (i.e., Linux and OSX, where I can check the documentation; it definitely doesn't work on Windows which lacks the API):
#include <dlfcn.h>
// ...
void *handle = dlopen(NULL, RTLD_LAZY);
void *thisfunction = handle ? dlsym(handle, __FUNCTION__) : NULL;
if (handle) dlclose(handle); // remember to close!
There are a number of other less-portable shortcuts that work on some platforms but not others. This is also not fast; cache it (e.g., in a local static variable) if you need speed.
No. In a three-letter answer. In C++ member functions you can have a "this" pointer that does something similar, but there's nothing equivalent in C.
However, since you can't define anonymous functions, there's little need for such a feature.
I realise this is likely not what you're after... but it still answers your question as it is currently phrased:
void someFunction()
{
void (*self)() = someFunction;
}
(Of course, here you could just as well use the identifier someFunction directly in most cases, instead of the function pointer self.)
If, however, you are looking for a means to do the same when you don't know what the current function is called (how could you ever get in such a situation, I wonder?), then I don't know a standard-compliant, portable way of doing this.
Looks like this has been asked before on SO, here is an interesting answer that I have not tested:
Get a pointer to the current function in C (gcc)?
Anyway, there are some interesting extensions, with gcc extensions, are you familiar with the __FUNCTION__ macro?
See what you think about this (this will just get you a string with the name of the function:
#include <stdio.h>
#include <stdlib.h>
void printme(char *foo)
{
printf("%s says %s\n", __FUNCTION__, foo);
}
int main(int argc, char *argv[])
{
printme("hey");
return 0;
}
Related
From this site, I learned the very exciting fact that you can load and run code from a shared library without explicitly compiling your program with it.
The following snippet of code illustrates how to use dlopen() (and associated functions) to run the double cos(double) function from C's math library (libm):
#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
int main(int argc, char **argv) {
void *handle;
double (*cosine)(double);
char *error;
handle = dlopen ("/lib/libm.so.6", RTLD_LAZY);
if (!handle) {
fputs (dlerror(), stderr);
exit(1);
}
cosine = dlsym(handle, "cos");
if ((error = dlerror()) != NULL) {
fputs(error, stderr);
exit(1);
}
printf ("%f\n", (*cosine)(2.0));
dlclose(handle);
}
As a hobby, I've been writing an interpreter (in C) for a custom language and I'd like to make it possible for the user to select a shared library and run code from it. I know this is possible, since many languages (including Python and J, both written in C) can dynamically call functions using dlopen(), only knowing at runtime what will be passed to and returned from the function.
However, I won't be able to predict ahead of time how I will need to cast the void pointer returned from dlsym(). In the above code, the programmer knew that the symbol they were going to look up ("cos") was a function using one double as a parameter and returning a double, so they knew how they had to cast the cosine variable to "pointer to function taking in a double and returning a double".
If I wanted to write a program where the user would specify a filename AND the function prototype, how could I write the underlying C code that would call dlsym() and call the function correctly?
My theory is that you would need to push parameters and pop return values from the process's stack directly (which I don't know how to do without inline assembly, which I'd like to avoid), but this is made complicated by the fact that you might need to pass a parameter through a register. Anyone know how to deal with this?
There is a well known library to solve this problem, used by many interpreted languages: libffi.
Internally, this library uses assembly code, of course, but it has so many HW and SW backends that you can consider it a portable solution.
For static functions I always put the static keyword in front of the function prototype at the beginning of the source file, while omitting it from its implementation.
So say I've got something like this:
#include <stdio.h>
static int foo(int bar);
int main(void) {
return foo(2);
}
int foo(int bar) {
printf("%d\n", bar);
return 0;
}
I have no technical reason to do so, I just think that all kind of necessary "meta-information" belongs to the prototype, and the implementation code is for... well, the implementation. I know it works, but I wanted to know:
Is it better practice to declare static in front of both the prototype and the implementation, or is it fine to do as shown above?
Same for inline.
The prototyp shall prototyp the function, so it shall carry everything the implementation does.
If you later than miss to add it to the implementation and the compiler knows the protoyp it implies it.
However, to avoid missunderstandings from the human reader's side also add it to the implementation.
I recommend to that definition and declaration should be same. There would be some compilers who will give error if functions mismatched! Your code will be not portable between comppilers
I'm trying to check a C program with Splint (in strict mode). I annotated the source code with semantic comments to help Splint understand my program. Everything was fine, but I just can't get rid of a warning:
Statement has no effect (possible undected modification through call to unconstrained function my_function_pointer).
Statement has no visible effect --- no values are modified. It may modify something through a call to an unconstrained function. (Use -noeffectuncon to inhibit warning)
This is caused by a function call through a function pointer. I prefer not to use the no-effect-uncon flag, but rather write some more annotations to fix it up. So I decorated my typedef with the appropriate #modifies clause, but Splint seems to be completely ignoring it. The problem can be reduced to:
#include <stdio.h>
static void foo(int foobar)
/*#globals fileSystem#*/
/*#modifies fileSystem#*/
{
printf("foo: %d\n", foobar);
}
typedef void (*my_function_pointer_type)(int)
/*#globals fileSystem#*/
/*#modifies fileSystem#*/;
int main(/*#unused#*/ int argc, /*#unused#*/ char * argv[])
/*#globals fileSystem#*/
/*#modifies fileSystem#*/
{
my_function_pointer_type my_function_pointer = foo;
int foobar = 123;
printf("main: %d\n", foobar);
/* No warning */
/* foo(foobar); */
/* Warning: Statement has no effect */
my_function_pointer(foobar);
return(EXIT_SUCCESS);
}
I've read the manual, but there's not much information regarding function pointers and their semantic annotations, so I don't know whether I'm doing something wrong or this is some kind of bug (by the way, it's not already listed here: http://www.splint.org/bugs.html).
Has anyone managed to successfully check a program like this with Splint in strict mode? Please help me find the way to make Splint happy :)
Thanks in advance.
Update #1: splint-3.1.2 (windows version) yields the warning, while splint-3.1.1 (Linux x86 version) does not complain about it.
Update #2: Splint doesn't care whether the assignment and the call are short or long way:
/* assignment (short way) */
my_function_pointer_type my_function_pointer = foo;
/* assignment (long way) */
my_function_pointer_type my_function_pointer = &foo;
...
/* call (short way) */
my_function_pointer(foobar);
/* call (long way) */
(*my_function_pointer)(foobar);
Update #3: I'm not interested in inhibiting the warning. That's easy:
/*#-noeffectuncon#*/
my_function_pointer(foobar);
/*#=noeffectuncon#*/
What I'm looking for is the right way to express:
"this function pointer points to a function which #modifies stuff, so it does have side-effects"
Maybe you are confusing splint by relying on the implicit conversion from "function name" to "pointer to function" in your assignment of my_function_pointer. Instead, try the following:
// notice the &-character in front of foo
my_function_pointer_type my_function_pointer = &foo;
Now you have an explicit conversion and splint doesn't need to guess.
This is just speculation, though. I haven't tested it.
I'm not familiar with splint, but it looks to me that it will check function calls to see if they produce an effect, but it doesn't do analysis to see what a function pointer points to. Therefore, as far as it's concerned, a function pointer could be anything, and "anything" includes functions with no effect, and so you'll continue to get that warning on any use of a function pointer to call a function, unless you so something with the return value. The fact that there's not much on function pointers in the manual may mean they don't handle them properly.
Is there some sort of "trust me" annotation for an entire statement that you can use with function calls through pointers? It wouldn't be ideal, but it would allow you to get a clean run.
I believe the warning is correct. You're casting a value as a pointer but doing nothing with it.
A cast merely makes the value visible in a different manner; it doesn't change the value in any way. In this case you've told the compiler to view "foobar" as a pointer but since you're not doing anything with that view, the statement isn't doing anything (has no effect).
Is something like this possible in C?
#include <stdio.h>
void print_str(char *str) {
printf(str);
}
int main() {
void (*f_ptr)() = print_str,"hello world";
f_ptr();
}
//see "hello world" on stdout
In short, I'd like to have a function pointer that "stores" the arguments. The point is that the function pointer can be used later on without needing a reference to the original data.
I could use something like this to couple a function pointer and an argument reference
struct f_ptr {
void (*f)();
void *data;
}
void exec_f_ptr(f_ptr *data) {
data->f(data->data):
}
but wouldn't be as elegant as just calling a function pointer with the argument inside.
What you want is a closure or a curried function. Unfortunately, C has neither of these. (Apple did introduce closures in its version of C and hopefully they'll be adopted for some future version of the language, but it's not part of C99.)
You're basically asking for a closure rather than a function pointer--that is, data and code in one "object." Such objects don't exist in standard C--you can get something similar from Apple's blocks or from anonymous functions in other languages (or from closures outright in the languages that support them) but generally speaking you'll have to construct some data type of your own, as you've discovered.
GLib has support for closures, used mainly for signal callbacks. It's cross platform, and might be worth a look (depending on your requirements). (See also the GLib closure API.)
No, that struct is the closest thing you're going to get
I am trying to do something like the following
enum types {None, Bool, Short, Char, Integer, Double, Long, Ptr};
int main(int argc, char ** args) {
enum types params[10] = {0};
void* triangle = dlopen("./foo.so", RTLD_LAZY);
void * fun = dlsym(triangle, ars[1]);
<<pseudo code>>
}
Where pseudo code is something like
fun = {}
for param in params:
if param == None:
fun += void
if param == Bool:
fun += Boolean
if param == Integer:
fun += int
...
returnVal = fun.pop()
funSignature = returnval + " " + funName + "(" + Riffle(fun, ",") + ")"
exec funSignature
Thank you
Actually, you can do nearly all you want. In C language (unlike C++, for example), the functions in shared objects are referenced merely by their names. So, to find--and, what is most important, to call--the proper function, you don't need its full signature. You only need its name! It's both an advantage and disadvantage --but that's the nature of a language you chose.
Let me demonstrate, how it works.
#include <dlfcn.h>
typedef void* (*arbitrary)();
// do not mix this with typedef void* (*arbitrary)(void); !!!
int main()
{
arbitrary my_function;
// Introduce already loaded functions to runtime linker's space
void* handle = dlopen(0,RTLD_NOW|RTLD_GLOBAL);
// Load the function to our pointer, which doesn't know how many arguments there sould be
*(void**)(&my_function) = dlsym(handle,"something");
// Call something via my_function
(void) my_function("I accept a string and an integer!\n",(int)(2*2));
return 0;
}
In fact, you can call any function that way. However, there's one drawback. You actually need to know the return type of your function in compile time. By default, if you omit void* in that typedef, int is assumed as return type--and, yes, it's a correct C code. The thing is that the compiler needs to know the size of the return type to operate the stack properly.
You can workaround it by tricks, for example, by pre-declaring several function types with different sizes of return types in advance and then selecting which one you actually are going to call. But the easier solution is to require functions in your plugin to return void* or int always; the actual result being returned via pointers given as arguments.
What you must ensure is that you always call the function with the exact number and types of arguments it's supposed to accept. Pay closer attention to difference between different integer types (your best option would be to explicitly cast arguments to them).
Several commenters reported that the code above is not guaranteed to work for variadic functions (such as printf).
What dlsym() returns is normally a function pointer - disguised as a void *. (If you ask it for the name of a global variable, it will return you a pointer to that global variable, too.)
You then invoke that function just as you might using any other pointer to function:
int (*fun)(int, char *) = (int (*)(int, char *))dlsym(triangle, "function");
(*fun)(1, "abc"); # Old school - pre-C89 standard, but explicit
fun(1, "abc"); # New school - C89/C99 standard, but implicit
I'm old school; I prefer the explicit notation so that the reader knows that 'fun' is a pointer to a function without needing to see its declaration. With the new school notation, you have to remember to look for a variable 'fun' before trying to find a function called 'fun()'.
Note that you cannot build the function call dynamically as you are doing - or, not in general. To do that requires a lot more work. You have to know ahead of time what the function pointer expects in the way of arguments and what it returns and how to interpret it all.
Systems that manage more dynamic function calls, such as Perl, have special rules about how functions are called and arguments are passed and do not call (arguably cannot call) functions with arbitrary signatures. They can only call functions with signatures that are known about in advance. One mechanism (not used by Perl) is to push the arguments onto a stack, and then call a function that knows how to collect values off the stack. But even if that called function manipulates those values and then calls an arbitrary other function, that called function provides the correct calling sequence for the arbitrary other function.
Reflection in C is hard - very hard. It is not undoable - but it requires infrastructure to support it and discipline to use it, and it can only call functions that support the infrastructure's rules.
The Proper Solution
Assuming you're writing the shared libraries; the best solution I've found to this problem is strictly defining and controlling what functions are dynamically linked by:
Setting all symbols hidden
for example clang -dynamiclib Person.c -fvisibility=hidden -o libPerson.dylib when compiling with clang
Then using __attribute__((visibility("default"))) and extern "C" to selectively unhide and include functions
Profit! You know what the function's signature is. You wrote it!
I found this in Apple's Dynamic Library Design Guidelines. These docs also include other solutions to the problem above was just my favorite.
The Answer to your Question
As stated in previous answers, C and C++ functions with extern "C" in their definition aren't mangled so the function's symbols simply don't include the full function signature. If you're compiling with C++ without extern "C" however functions are mangled so you could demangle them to get the full function's signature (with a tool like demangler.com or a c++ library). See here for more details on what mangling is.
Generally speaking it's best to use the first option if you're trying to import functions with dlopen.