how to use function pointers in C

What are function pointers C?

Think of a function pointer as a name tag for a function. When you write a function like calculate(), you give it a name. A function pointer is a variable that can hold that name—not the function's code itself, but a reference to it. You can then use that variable to "call" the function indirectly, just like using a nickname to find someone in a crowd.

A common misconception is that a function pointer is "just a memory address." While it stores an address, that address points to executable code, not to data like a regular pointer. The key difference is what the address points to and how you use it.

So, a function pointer is more than an address—it's a typed handle to executable code, and the compiler uses its type to keep your calls safe and correct.

int add(int a, int b) { 
    return a + b; 
}

int (*operation)(int, int) = add;  
int result = operation(2, 3);      // Calls add(2, 3) indirectly

C Function Pointers Tutorial: Basic Syntax

Let's decode the syntax. In C, the asterisk * is your signal. When you see int *p, the compiler knows p isn't an integer—it's an address to an integer.

With function pointers, we use that same logic. The * tells the compiler: "This variable stores an address, specifically the address of a block of executable code."

Remember the pattern: return_type (*pointer_name)(parameters). The parentheses are your safety net—they ensure you are creating a variable, not defining a new function.

How to Use Function Pointers for Callbacks

Imagine you are building a universal socket for electrical devices. You don't know exactly what device the user will plug in—a lamp, a toaster, or a fan. You just know the socket needs to fit the plug.

In C, a callback is exactly this. You write a general-purpose tool (the socket) that accepts a function pointer (the plug). The user provides the specific behavior (the device) later. This makes your code modular and reusable.

In the example above, process_items is the tool. It iterates through a list of numbers. It doesn't care what it does with them—it just needs a function that accepts an integer and returns nothing.

typedef void (*callback_t)(int);

// 1. The Tool: Accepts a callback
void process_items(callback_t cb) {
    // The tool calls the function for every item
    for (int i = 0; i < 3; i++) {
        cb(i);  
    }
}

// 2. The Callback: Matches the signature
void print_number(int n) {
    printf("Item: %d\n", n);
}

int main() {
    // 3. Pass the function name (decays to pointer)
    process_items(print_number); 
    // Output: Item: 0, Item: 1, Item: 2
    return 0;
}

Why the Compiler Cares

You might think, "Why not just let me pass any function? The computer can figure it out."

The answer lies in the Calling Convention. When C calls a function, it prepares the stack (memory) in a specific way based on the function's signature.

This is why the typedef is your safety net. It creates a strict contract. If you try to pass int get_val(char) to a tool expecting void (*)(int), the compiler stops you immediately.

Common Misconceptions About Function Pointers

Now that we know how to write them, let's talk about how they behave. Beginners often trip over two specific traps: confusing the pointer with the function, and thinking the compiler is flexible about types.

Notice what happens when you try to force a mismatch. The compiler isn't being difficult; it's protecting you.

Why the Machine Cares: Calling Conventions

When you call a function, the computer follows a strict set of rules called the Calling Convention. It decides:

• How many arguments to push onto the stack.
• Where to put them (stack vs. CPU registers).
• Whether to expect a return value.

This is why we use typedef. It creates a rigid contract. If you try to break the contract, the compiler stops you before your program even runs.

Pitfalls and Debugging Tips for C Function Pointers

Debugging function pointers can feel like chasing a moving target. Remember our Remote Control analogy? The TV (the function code) stays in the same place in memory forever. But the Remote (the pointer variable) can be lost, broken, or unplugged.

When your program crashes, the problem is almost never the TV itself. It's usually the remote: Is it pointing at the right channel? Is the battery dead (NULL)?

The Golden Rule: Never trust a function pointer without checking it first. Always initialize it to NULL and verify before calling.

By printing the pointer value, you get a direct window into the state of your program. It's the fastest way to confirm if your "remote control" is actually plugged into the wall.

Building Modular Code with Function Pointers

Think of a well-designed system as a team of specialists. The project manager (your core logic) doesn't need to know how the electrician or plumber does their job—only that they have a specific tool (function signature) they can hand over when needed.

A function pointer is that tool specification. When you pass a callback, you're inverting control: instead of your core code calling a specific, hardcoded function, it says, "You, caller, provide any function that fits this shape, and I'll call it at the right time." This decouples who does the work from when and why it gets done.

void process_all(int* data, int count, void (*process)(int)) {
    // Manager handles the loop, not the logic
    for (int i = 0; i < count; i++) {
        process(data[i]);  // Delegates work
    }
}

void square_and_print(int x) { 
    printf("%d squared is %d\n", x, x*x); 
}

int main() {
    int values[] = {1, -2, 3};
    // You can swap specialists without changing the manager!
    process_all(values, 3, square_and_print); 
}

Here, process_all is reusable for any operation on an integer. The team manager doesn't change—only the specialist you hand it.

Common Misconception: More Pointers = Better Modularity?

You might think: "If a little decoupling is good, then passing function pointers everywhere must be great."

Not true. Overusing function pointers can make code harder to follow, not easier. Each function pointer is an indirection—a "go find the real code somewhere else" detour.

When to Avoid Overusing Function Pointers

Use function pointers for true variability, not as a default pattern. Avoid them when:

Advanced Topics: Arrays, Dynamic Allocation, and Higher-Order Functions

We've mastered the basics: declaring pointers, calling them, and using them for callbacks. But function pointers are powerful because they behave just like data pointers.

This means you can pass them to other functions, store them in arrays, and even allocate them on the heap. Let's explore these advanced capabilities.

// The Executor: Takes a function pointer as an argument
void repeat(void (*action)(), int times) {
    for (int i = 0; i < times; i++) {
        action();  // Call the passed function
    }
}

void say_hello() { 
    printf("Hello!\n"); 
}

int main() {
    repeat(say_hello, 3);  // Pass the token!
    // Output: Hello! Hello! Hello!
    return 0;
}

void cmd_start() { printf("Started\n"); }
void cmd_stop()  { printf("Stopped\n"); }
void cmd_status(){ printf("Running\n"); }

int main() {
    // Array of 3 function pointers
    void (*commands[3])() = { cmd_start, cmd_stop, cmd_status };

    int choice = 1; // User picks index 1
    
    // Call the function at that index
    commands[choice]();  // Calls cmd_stop()
    return 0;
}

void handler_a() { printf("A\n"); }
void handler_b() { printf("B\n"); }

int main() {
    // 1. Allocate space for a pointer variable
    void (**ptr)() = malloc(sizeof(void (*)()));
    
    // 2. Assign a function to it
    *ptr = handler_a; 
    
    // 3. Call it
    (*ptr)(); 
    
    // 4. Clean up (only the pointer, not the function!)
    free(ptr);
    return 0;
}

Remember: free(ptr) only releases the memory for the pointer variable. The function code itself remains in the static memory segment for the life of the program.

Frequently Asked Questions (FAQ)

You've reached the end of the journey, but you probably still have a few questions. Let's tackle the most common confusions beginners face with function pointers. I'll answer them clearly, with a few interactive visuals to help the concepts stick.

void foo() { printf("Hello\n"); }
void bar() { printf("World\n"); }

int main() {
    // 1. Initialize
    void (*callback)() = foo; 
    
    callback();  // Output: Hello

    // 2. Reassign at runtime
    callback = bar; 
    
    callback();  // Output: World
    return 0;
}

// The 'caller' expects a function that takes an int and returns void
void caller(void (*cb)(int)) {
    // Call it like a normal function
    cb(42); 
}

void my_callback(int x) { 
    printf("Got: %d\n", x); 
}

int main() {
    // Pass the function name (decays to pointer)
    caller(my_callback); 
    return 0;
}

void (*ptr)();

typedef struct {
    void (*log)(const char*);  // Method inside struct
} Logger;