Can I get the info of the who call the callback?

[s88]

Hello....
Consider the follows callback function...

typedef void (* CALLBACK) (int);
void some_callback(int percentage){
fprintf(stderr, "%d\%\n", percentage);
}
void function1(CALLBACK callback){
....
callback( parameters...);
....
}

How do I know which function calls the callback function in the
function some_callback(int percentage).

Thanx!!

 

[Chris Dollin]

Hello....
Consider the follows callback function...

typedef void (* CALLBACK) (int);
void some_callback(int percentage){
fprintf(stderr, "%d\%\n", percentage);
}
void function1(CALLBACK callback){
....
callback( parameters...);
....
}

How do I know which function calls the callback function in the
function some_callback(int percentage).

You will have to arrange for that information to be passed to
the callback function somehow.

There's no way in C for it to find out; and in fact it's possible
that, even if you resorted to implmentation-specific stack magic,
that the calling function's footprints are no longer there.

 

[tuncay tekle]

How do I know which function calls the callback function in the
function some_callback(int percentage).

If I were you, I would have a global variable, and set it to some
number (probably with enumeration) before calling the callback.
Parametrization is also another idea, but it seems to me that the
global variable idea is more efficient.

 

[Christopher Benson-Manica]

Parametrization is also another idea, but it seems to me that the
global variable idea is more efficient.

IMHO, global variables are not usually a good idea. They are a
hard-to-maintain hack in most cases, and I think passing some
parameter to the callback indicating the caller's identity would be
much more intuitive to boot. <ot>Not to mention that in a
multithreaded environment, global variables get to be a much bigger
hassle.</ot>

 

[Emmanuel Delahaye]

tuncay tekle a écrit :

If I were you, I would have a global variable, and set it to some
number (probably with enumeration) before calling the callback.
Parametrization is also another idea, but it seems to me that the
global variable idea is more efficient.

Globals are evil.

The good solution is an origin parameter enclosed in a simple wrap:

struct param
{
/* to be defined */
enum origin origin;

/* user data */
void *p_user;
};

 

[David Shin]

If you're using gcc, you could make good use of the GNU hook functions.

GNU provides hooks to capture whenever an instrumented function is
called or exits with these prototypes:

void __cyg_profile_func_enter(void *func_address, void *call_site);
void __cyg_profile_func_exit(void *func_address, void *call_site);

 

[tuncay tekle]

Globals are evil.

I know they are but I think that in terms of *efficiency*, it looks
better for this case (although it's not a big deal). Globals are only
evil to the programmer , you have to be over-careful, but sometimes
using them does pay off.

 

[Mark F. Haigh]

Hello....
Consider the follows callback function...

typedef void (* CALLBACK) (int);
void some_callback(int percentage){
fprintf(stderr, "%d\%\n", percentage);
}
void function1(CALLBACK callback){
....
callback( parameters...);
....
}

How do I know which function calls the callback function in the
function some_callback(int percentage).

I've seen things like this done before:

#include <stdio.h>

typedef void (*CALLBACK)(const char *, int);

void callback(const char *caller, int percentage)
{
printf("caller: %s, percentage: %d%%\n",
caller, percentage);
}

void function1(CALLBACK cb)
{
cb(__func__, 42);
}

int main(void)
{
function1(callback);
return 0;
}

[mark@icepick ~]$ ./foo
caller: function1, percentage: 42%
[mark@icepick ~]$

Kind of hackish, though. You should probably avoid it if you can.
Technically, __func__ is a C99ism, but most C89 compilers have
something like it you can use.


Mark F. Haigh
(e-mail address removed)

 

[Mike Wahler]

I know they are but I think that in terms of *efficiency*,

With today's compilers and computers, I suspect there's
no measurable difference.

it looks
better for this case
Why?

(although it's not a big deal). Globals are only
evil to the programmer ,

It's the programmer that must maintain the code.
Global objects are more 'brittle' (subject to
erroneous usage), than scoped ones.

you have to be over-careful, but sometimes
using them does pay off.

How?

-Mike