Function Pointers in C: Storing and Calling Functions Dynamically

Quick Recap: The Facts You Need

A function has an address. Used without parentheses, the function's name gives you that address:

int add(int a, int b) {
    return a + b;
}
add // the address of the function (no call)add(2, 3)    // calling it (parentheses)

To store that address, the pointer's type must describe the function's shape — return type and parameter types:

int(*op)(int, int);
// pointer to a function taking two ints, returning int
op = add;
// store the addressprintf("%d\n", op(2, 3));
// call through the pointer → 5

Read the declaration right-to-left from the name: "op is a pointer to a function taking (int, int) and returning int."

Two non-negotiables:

• The parentheses around *op are mandatory.int *op(int, int) declares a function returning an int * — completely different. Drop those parentheses and you've written something else entirely.
• The shape must match. You can only store functions whose return and parameter types match the pointer exactly.

That's the groundwork. If any of it feels shaky, the earlier callbacks tutorial covers the declaration/calling basics in more depth — this page assumes it and moves on to making function pointers useful as data.

Typedef: Making It Readable

Raw function pointer syntax is genuinely unpleasant to read and easy to mistype. The typedef fixes that:

typedef int(*BinaryOp)(int, int);

Now BinaryOp is a type name meaning "pointer to a function taking two ints and returning int":

BinaryOp op = add;
// cleanBinaryOp table[4];
// an array of themvoid registerOp(BinaryOp fn);
// a parameterBinaryOp getOp(int index);
// a return type

Compare with the raw form in each case:

int(*op)(int, int) = add;
int(*table[4])(int, int);
void registerOp(int(*fn)(int, int));
int(*getOp(int index))(int, int);
// ← this one is genuinely hard to parse

That last line is the real argument for typedefs. Complex function pointer declarations become unreadable very quickly, and a typedef collapses them into something you can reason about.

Adopt this habit immediately: define the typedef once at the top of your file, use it everywhere. It's the single biggest readability improvement you can make with function pointers.

(Suggested image: a before/after comparison graphic — the raw int (*getOp(int))(int,int) next to the typedef version with a "much better" checkmark)

Array of Function Pointers: The Dispatch Table

Here's where function pointers stop being a curiosity and start replacing real code.

Consider a calculator with four operations. The switch version (which you've seen in the control flow cluster) works fine:

switch (op) {
    case '+': result = a + b;
    break;
    case '-': result = a - b;
    break;
    case '*': result = a * b;
    break;
    case '/': result = a / b;
    break;
}

Now the function pointer version:

#include <stdio.h>
typedef int(*BinaryOp)(int, int);
int add(int a, int b) {
    return a + b;
}
int sub(int a, int b) {
    return a - b;
}
int mul(int a, int b) {
    return a * b;
}
int divide(int a, int b) {
    return(b != 0) ? a / b : 0;
}
int main(void) {
    BinaryOp operations[4] = {
        add, sub, mul, divide
    };
    int a = 12, b = 4;
    for (int i = 0; i < 4; i++) {
        printf("op[%d](%d, %d) = %d\n", i, a, b, operations[i](a, b));
    }
    return 0;
}

Output:

op[0](12, 4) = 16op[1](12, 4) = 8op[2](12, 4) = 48op[3](12, 4) = 3

The array is a table of behaviors. Index 0 adds, index 1 subtracts, and so on. And now the selection can happen at runtime:

char symbols[] = {
    '+', '-', '*', '/'
};
int choice;
printf("Pick (0-3): ");
scanf("%d", &choice);
if (choice >= 0 && choice < 4) {
    printf("%d %c %d = %d\n", a, symbols[choice], b, operations[choice](a, b));
}

Compare the two designs:

The table version doesn't just look neater — it changes the shape of the code. The operation is no longer baked into control flow; it's data you can index, pass, store, and select.

(Suggested image: two side-by-side code panels — a long switch ladder next to a compact array — with an arrow from "runtime index" into the array)

A State Machine With Function Pointers

The dispatch-table idea scales to a genuinely powerful pattern: a state machine, where each state is a function and transitions are table lookups. This is how parsers, protocol handlers, and game AI are structured.

#include <stdio.h>
// Each state handler returns the NEXT statetypedef int (*StateHandler)(const char *input);
enum {
    STATE_START, STATE_IDLE, STATE_PROCESSING, STATE_DONE
};
int handleStart(const char *input) {
    printf("  [START] got '%s' — moving to IDLE\n", input);
    return STATE_IDLE;
}
int handleIdle(const char *input) {
    printf("  [IDLE] got '%s' — moving to PROCESSING\n", input);
    return STATE_PROCESSING;
}
int handleProcessing(const char *input) {
    if (input[0] == 'q') {
        printf("  [PROCESSING] quit signal — moving to DONE\n");
        return STATE_DONE;
    }
    printf("  [PROCESSING] got '%s' — staying put\n", input);
    return STATE_PROCESSING;
}
int handleDone(const char *input) {
(void)input;
    // unused here — silences the warning    printf("  [DONE] ignoring '%s'\n", input);    return STATE_DONE;}
    int main(void) {
        // The state table: index = state number, value = handler for that state    StateHandler table[] = { handleStart, handleIdle, handleProcessing, handleDone };    const char *names[]  = { "START", "IDLE", "PROCESSING", "DONE" };
        int state = STATE_START;
        const char *inputs[] = {
            "hello", "world", "quit", "anything"
        };
        int numInputs = 4;
        for (int i = 0; i < numInputs && state != STATE_DONE; i++) {
            printf("State %-11s ", names[state]);
            state = table[state](inputs[i]);
            // ← dispatch: look up, then call    }
            printf("Final state: %s\n", names[state]);
            return 0;
        }

Sample Run:

State START [START] got 'hello' — moving to IDLEState IDLE [IDLE] got 'world' — moving to PROCESSINGState PROCESSING [PROCESSING] got 'quit' — moving to DONEFinal state: DONE

Look at that dispatch line:

state = table[state](inputs[i]);

The current state value indexes directly into the handler table, and the handler's return value becomes the next state. No switch, no chain of ifs — the control flow is completely data-driven.

Adding a new state means adding one handler function and one array entry (and, in a real implementation, a transitions table). The main loop never changes. That property — new behavior without editing the dispatcher — is exactly what makes these patterns valuable in large systems.

(Suggested image: the state machine diagram — four circular states with arrows, and beneath it the array indexed by state showing which function each slot points to)

Returning a Function Pointer From a Function

A function can hand back a function pointer — letting the caller decide which behavior to use next:

#include <stdio.h>
typedef int(*Operation)(int, int);
int add(int a, int b) {
    return a + b;
}
int mul(int a, int b) {
    return a * b;
}
// Returns a function pointer, chosen by the caller's modeOperation selectOperation(char mode) {    if (mode == '+') return add;    if (mode == '*') return mul;    return NULL;                        // no suitable operation}
int main(void) {
    Operation op = selectOperation('*');
    if (op != NULL) {
        printf("Result: %d\n", op(6, 7));
        // 42    }
        return 0;
    }

Output:

Result: 42

Note the declaration syntax for the function itself — this is where typedefs earn their keep:

Operation selectOperation(char mode);
// with typedef — clearint (*selectOperation(char mode))(int, int);
// without — hard to parse

Both are correct; the typedef version is what you'd actually write.

Always check the returned pointer for NULL before calling it. A function that returns "no suitable behavior" has to return something, and NULL is the honest choice — it's exactly what the DANGER of uninitialized function pointers looks like when done safely.

Storing State: Function Pointers in Structs

Combining function pointers with structures gives you something that resembles object-oriented dispatch — a "vtable" of behaviors attached to data:

#include <stdio.h>
typedef struct {
    const char *name;
    void(*speak)(void);
    int(*legs)(void);
}
Animal;
void dogSpeak(void) {
    puts("Woof!");
}
void catSpeak(void) {
    puts("Meow!");
}
void birdSpeak(void) {
    puts("Tweet!");
}
int dogLegs(void) {
    return 4;
}
int catLegs(void) {
    return 4;
}
int birdLegs(void) {
    return 2;
}
int main(void) {
    Animal zoo[3] = {
{
            "Dog", dogSpeak, dogLegs
        }
        , {
            "Cat", catSpeak, catLegs
        }
        , {
            "Bird", birdSpeak, birdLegs
        }
    };
    for (int i = 0; i < 3; i++) {
        printf("%-5s (%d legs): ", zoo[i].name, zoo[i].legs());
        zoo[i].speak();
        // dispatch through the struct field    }
        return 0;
    }

Output:

Dog(4 legs): Woof!
Cat(4 legs): Meow!
Bird(2 legs): Tweet!

Each struct carries its own behavior. The loop calls zoo[i].speak() without any knowledge of which animal it's dealing with — the function pointer field decides.

This pattern shows up constantly in real code: device drivers (a struct of operation pointers), file system abstractions, protocol handlers. It's the closest C gets to polymorphism, and it's built entirely from the mechanism on this page.

When a Dispatch Table Beats a switch (And When It Doesn't)

Honest guidance, because tables aren't automatically better:

Use a dispatch table when:

• There are many options (10+), making the switch unwieldy
• Options are added frequently — the table localizes the change
• Behavior must be data-driven (a plugin list, a config file, a state machine)
• You need to pass behavior around or store it
• Different option sets exist at different times (multiple tables, swapped in and out)

Keep the switch when:

• There are 3–5 options (a table adds indirection for no gain)
• Each case does something different in kind (not a uniform signature)
• Cases have complex, heterogeneous logic — forcing them into identical signatures distorts the design
• Readability matters most and the switch is clearer

One more consideration: dispatch tables replace the compiler's ability to warn you about missing cases. With a switch, some compilers warn if you don't handle every enum value; with an array, a forgotten entry is a NULL at runtime. If you use tables, consider an initialization check or a NULL-guard at the dispatch site.

(Suggested image: a decision list graphic — "many uniform operations / added often / data-driven → table; few / varied / fixed → switch")

Common Mistakes

1. Dropping the parentheses in the declaration — int *fn(int, int) is a function returning int *, not a function pointer. Always int (*fn)(int, int).
2. Signature mismatch — assigning a function whose parameter or return types don't match the pointer's. Produces warnings and undefined behavior when called.
3. Calling through a NULL function pointer — instant crash. Always check after a selection function or table lookup that could return NULL.
4. Using uninitialized function pointers — an uninitialized pointer holds garbage; calling it jumps to a random address. Initialize to NULL or a real function.
5. Forgetting & semantics — fn = add and fn = &add are both fine, but be consistent. Likewise fn(1,2) and (*fn)(1,2) are equivalent; pick one style.
6. Array size mismatches — declaring BinaryOp table[4] but initializing with 5 functions (compile error, luckily) or leaving slots uninitialized (dangling call at runtime).
7. Assuming the compiler checks argument types when calling through a pointer — it does check against the pointer's declared signature, so if the pointer's type is wrong, the check is wrong too. Get the typedef right and this is safe.
8. Over-applying the pattern — not every switch wants to be a table. Forced uniformity can make code harder to read than the thing it replaced.
9. Forgetting that a table of void (*)(void) functions can't return anything — if handlers need to report results, the signature must carry that. Design the signature first.

(Suggested image: "9 Function Pointer Mistakes" checklist graphic — consistent with the series)

Final Thoughts

Function pointers turn C's functions into first-class data: things you can store, index, pass, return, and select at runtime. The syntax is awkward (which is why typedefs are mandatory in practice), but the capability is genuinely powerful — dispatch tables, state machines, and vtable-style structures all come from this one mechanism.

The mental shift worth taking away: a function pointer is a variable whose value happens to be executable code. Once you can index into an array of them — table[state](input) — you can express control flow as data, and that's a genuinely different way to design programs.