Function Pointers in C — NULL Crash in Embedded Firmware

Every non-trivial C program eventually hits a wall: you need a piece of code to behave differently depending on context, but you don't want to litter your logic with a dozen if-else branches. Sort algorithms need comparison logic. Event loops need to dispatch to different handlers. Plugin systems need to call code that didn't exist when the core was compiled. In every one of these cases, function pointers are the tool C gives you — and understanding them is what separates C programmers who write clever hacks from those who write clean, extensible systems.

The problem function pointers solve is simple: in C, functions are not first-class values you can pass around the way you'd pass an integer. But their addresses are. A function pointer stores that address, which means you can store a function in a variable, pass it as an argument, return it from another function, or keep a whole table of them. This is how the C standard library's qsort works, how operating system kernels register interrupt handlers, and how game engines implement entity behavior without a class hierarchy.

By the end of this article you'll be able to declare and call function pointers without second-guessing the syntax, build a working callback system, construct a dispatch table that replaces a cascade of if-else statements, and spot the two errors that burn every developer the first time they use function pointers in production code.

Declaring and Calling a Function Pointer — Getting the Syntax Right Once and For All

The syntax for function pointers trips people up because the asterisk belongs to the name, not the return type. Read the declaration from the inside out: the name of the variable is in the middle, wrapped in parentheses with an asterisk, and the surrounding parts describe what function signature it can point to.

For a function that takes two ints and returns an int, the pointer type is: int (operation)(int, int). That parentheses around operation is mandatory — without it, int operation(int, int) is a completely different thing: a function named operation that returns int .

Once you have the pointer, calling it is straightforward. Modern C allows you to call it directly as operation(a, b) — the compiler knows it's a pointer and handles the dereference. The older explicit-dereference syntax (*operation)(a, b) also works and makes the pointer nature more obvious. Both styles are valid; pick one and be consistent within a codebase.

#include <stdio.h>

/* 
 * io.thecodeforge naming convention applied to math operations 
 * All share the signature: (int, int) -> int
 */
int tcf_add(int a, int b)      { return a + b; }
int tcf_subtract(int a, int b) { return a - b; }
int tcf_multiply(int a, int b) { return a * b; }

// Typedef makes the syntax human-readable
typedef int (*MathOperation)(int, int);

int main(void) {
    // Pointer assignment (no & required, though valid)
    MathOperation operation = tcf_add;

    printf("tcf_add(10, 4)      = %d\n", operation(10, 4));

    operation = tcf_subtract;
    printf("tcf_subtract(10, 4) = %d\n", operation(10, 4));

    operation = tcf_multiply;
    printf("tcf_multiply(10, 4) = %d\n", operation(10, 4));

    return 0;
}

Callbacks — Passing Functions as Arguments the Way qsort Does

A callback is nothing more than a function pointer you pass to another function so that function can call yours at the right moment. It's the foundational pattern behind event-driven systems, custom sorting, plugin architectures, and async I/O notification.

The C standard library's qsort is the example every C programmer meets first. You hand qsort your array and a comparator — a function pointer that tells qsort how to decide which of two elements is 'less than' the other. qsort doesn't care what you're sorting or how you define order; it just calls your comparator whenever it needs to compare two elements.

Building your own callback-based API follows the same pattern. You design a function that accepts a function pointer parameter. Callers provide different functions to customize behavior. Your core logic stays untouched.

#include <stdio.h>
#include <stdlib.h>

namespace io_thecodeforge {

typedef struct {
    char name[32];
    int  score;
} TcfPlayer;

// Comparator for qsort: descending order
int tcf_compare_descending(const void *a, const void *b) {
    const TcfPlayer *pa = (const TcfPlayer *)a;
    const TcfPlayer *pb = (const TcfPlayer *)b;
    return pb->score - pa->score;
}

// Predicate callback type
typedef int (*TcfPredicate)(const TcfPlayer *p);

void tcf_filter_players(TcfPlayer *list, int n, TcfPredicate should_print) {
    for (int i = 0; i < n; i++) {
        if (should_print(&list[i])) {
            printf("  %s: %d\n", list[i].name, list[i].score);
        }
    }
}

int tcf_is_pro(const TcfPlayer *p) { return p->score >= 90; }

}

int main(void) {
    using namespace io_thecodeforge;
    TcfPlayer team[] = {{"Alice", 95}, {"Bob", 45}, {"Charlie", 92}};
    int n = 3;

    qsort(team, n, sizeof(TcfPlayer), tcf_compare_descending);
    
    printf("Pro Players Only:\n");
    tcf_filter_players(team, n, tcf_is_pro);

    return 0;
}

Dispatch Tables — Replacing if-else Chains With an Array of Function Pointers

Once you can store a function pointer in a variable, you can store them in an array. An array of function pointers is called a dispatch table (or jump table), and it's one of the most useful patterns in systems programming.

Consider a simple calculator that handles four operations. The naive approach is a chain of if-else or a switch statement. That works for four operations, but what about forty? You'd have forty branches, and adding a new operation means touching the dispatcher every single time.

A dispatch table maps an index (or enum value) directly to a function. Adding a new operation is adding one entry to the table. The dispatcher doesn't change at all.

#include <stdio.h>
#include <string.h>

typedef void (*TcfHandler)(const char *arg);

void tcf_log_info(const char *msg)  { printf("[INFO] %s\n", msg); }
void tcf_log_error(const char *msg) { printf("[ERROR] %s\n", msg); }

typedef struct {
    const char *cmd;
    TcfHandler action;
} TcfRoute;

static const TcfRoute routes[] = {
    {"info",  tcf_log_info},
    {"error", tcf_log_error}
};

void tcf_dispatch(const char *cmd, const char *msg) {
    for (size_t i = 0; i < 2; i++) {
        if (strcmp(routes[i].cmd, cmd) == 0) {
            routes[i].action(msg);
            return;
        }
    }
    printf("Unknown command\n");
}

int main() {
    tcf_dispatch("info", "System start");
    tcf_dispatch("error", "Disk full");
    return 0;
}

Function Pointers in Structs — How C Fakes Object-Oriented Design

If you put function pointers inside a struct, the struct gains behavior — it's not just data anymore. This is exactly how C++ implements virtual functions under the hood (the vtable).

This pattern works by defining a struct that holds function pointer fields. Different 'instances' can point their pointers at different implementations. Code that operates on the struct calls the function through the pointer without knowing which implementation it's talking to.

This matters because C is used where C++ isn't an option — microcontrollers and kernels. Knowing how to build a clean interface with function pointers lets you write reusable C code rather than copying logic for every new variant.

#include <stdio.h>

typedef struct TcfLogger TcfLogger;

struct TcfLogger {
    void (*write)(const char *msg);
};

void tcf_console_write(const char *msg) { printf("Console: %s\n", msg); }
void tcf_file_write(const char *msg)    { printf("File: %s\n", msg); }

int main() {
    TcfLogger console = { tcf_console_write };
    TcfLogger file    = { tcf_file_write };

    TcfLogger *loggers[] = { &console, &file };

    for(int i = 0; i < 2; i++) {
        loggers[i]->write("TCF Polymorphism Test");
    }

    return 0;
}

State Machines with Function Pointers — Clean Event Handling Without Switch Statements

State machines are everywhere — protocol handlers, UI navigation, game states. The textbook approach uses a switch statement with a state variable. That works, but as states grow, the switch becomes a maintenance nightmare. Function pointers offer a cleaner alternative: each state is a function, and the state machine's current state pointer is a function pointer. Transitioning to a new state is as simple as reassigning the pointer.

This pattern is common in embedded systems where memory is tight and you need deterministic timing. Each state function receives events and returns the next state function pointer. The main loop simply calls the current state function in a tight loop, consuming no additional stack depth.

Implementing this avoids the risk of missing a state in a switch, keeps state logic isolated, and makes adding new states trivial — just write a new function and register it.

#include <stdio.h>

typedef struct TcfEvent TcfEvent;
struct TcfEvent {
    int type;
    int data;
};

// Forward declarations of state functions
typedef void (*TcfState)(const TcfEvent *event, TcfState *next);

void tcf_state_idle(const TcfEvent *event, TcfState *next) {
    printf("Idle state\n");
    if (event->type == 1) {
        *next = tcf_state_active;
    } else {
        *next = tcf_state_idle;
    }
}

void tcf_state_active(const TcfEvent *event, TcfState *next) {
    printf("Active state\n");
    if (event->type == 2) {
        *next = tcf_state_idle;
    } else {
        *next = tcf_state_active;
    }
}

int main() {
    TcfState current = tcf_state_idle;
    TcfEvent events[] = {{1, 0}, {1, 0}, {2, 0}, {1, 0}};
    for (int i = 0; i < 4; i++) {
        current(&events[i], &current);
    }
    return 0;
}