Getting the address of a function in C ?

[Perica]

..

[BI lazy]

In C as in ASM the name of the function is nothing else but its starting address (or offset).

To obtain the adress of a function, just define a pointer being able to hold the adress of the function.

typedef (int)(* function)(int x,int y,int c);
function setpix;

your function:
int setpixel1(int x,int y,int c);

where you feel like it you put a line like this in your code:

setpix=setpixel1;

mark: the definition of the pointer has to reflect the return value as well as the passed parameters of the functions you want to abstract with it. Hope I've explained it clearly enough.

[Pype.Clicker]

if you *really* want to store the function address as an integer (but you shouldn't want to do this), you need an additionnal cast.

Code: Select all

void myFunction(int, int);
DWORD why=(DWORD)myFunction;

[Perica]

..

[Schol-R-LEA]

The problem is not with accessing a pointer to a function, but with casting the pointer to a DWORD rather than storing it as a pointer variable. As it has been mentioned before, this assumes the implementation of the pointers, which may not be correct on other processors (e.g., Itanium) or memory models. Also, it breaks typing; while in a given system, both integers and function pointers may be implemented as 32-bit values, they are conceptually quite different, and confusing them is likely to lead to problems. Finally, if you ever need to do pointer arithmetic on the value (unlikely but possible), you would have to manually include the offsets if it is stored as an integer, where as if stored as a pointer, the calculations are made automatically for you by the compiler

So, the preferable approach would be to declare them as:

Code: Select all

int myfunction(int x, y int);

int (* why)(int x, int y);

or else use a [tt]typedef[/tt] to create a function pointer type, as Beyond Infinity's example:

Code: Select all

int myfunction(int x, y int);

typedef (int) (* QUERY) (int x, int y);

QUERY why = myfunction;

HTH. C&CW.

[Pype.Clicker]

beyond the arguments Schol-r-lea provided, there's the risk you'll call the function with the wrong arguments. Suppose you have a function F of type Fproto:

Code: Select all

 typedef char* (toStringFct)(void* object);
 toStringFct myObjectToString;

 DWORD hell=(DWORD)myObjectToString;

And suppose you cast this to a dword. Now, in order to call your function, you'll need to cast it to a type function too. Problems arise if you don't cast it to Fproto (toStringFct) but rather to another type.

Code: Select all

   printf("%s",((toStringFunction*)hell)(&myObject)); // correct
   if (((compareFct*)hell)(&Object1, &Object2)) // design error.

The problem you'll quickly face is that your compiler is unable to detect these error. There's nothing that prevent it from casting a dword to any function type (oh, maybe it'll throw a warning, but this will be regardless of whether your cast is correct or not).

If you keep

Code: Select all

struct myClass {
   toStringFct *tostring;
   compareFct *cmp;
};

myClass.tostring=myObjectToString;

everything will be *much* simpler.

[df]

but then, moving to c++ would be even more easier.

if i am, in c, going to store the address of a function, i just cast it as void*, since its a pointer it allocates the correct size...

one of my apps did have an array of function pointers, but with all having same arguments, it was safe...

sarien uses pointers to functions for abstration on its sound/gfx/file drivers etc...

[Pype.Clicker]

but then, moving to c++ would be even more easier.

provided that you know C++ enough, yes, indeed. However, i don't think it's a valid reason to do things correctly in C (if you decided to do them in C). using void* for storing functions sounds much like using #define for property flags when you have constructs like enums and bitfield that are available and that allow the compiler to track bugs better ...