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.

What a Function Pointer Actually Is

A function pointer stores the address of a function in memory, allowing you to call that function indirectly through the pointer. In C, a function name decays to a pointer to the function's entry point, just as an array name decays to a pointer to its first element. The declaration syntax mirrors the function signature: return_type (*ptr_name)(parameter_types). This indirection is the core mechanic — you can pass functions as arguments, store them in arrays, or assign them at runtime. Function pointers have a fixed size (typically 4 or 8 bytes, matching the platform's pointer width) and can be compared for equality. Dereferencing a NULL function pointer causes an immediate crash — often a hard fault on embedded systems — because the processor jumps to address zero. This is not a recoverable error; it's a silent, catastrophic failure. Use function pointers when you need runtime polymorphism without C++ overhead: callback registration, state machines, command dispatch tables, or plugin architectures. In embedded firmware, they are essential for decoupling hardware drivers from application logic — for example, a timer driver that calls a user-defined callback on overflow. The cost is one extra indirection per call (negligible on most MCUs) and the risk of NULL dereference if not validated.

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;
}

Where Functions Live — The Address You Never Knew You Needed

Every function you write sits in memory at a specific address. Just like a variable, a function name without parentheses evaluates to its entry point. This isn't trivia — it's the whole reason function pointers exist. When you write multiply instead of multiply(), you're grabbing an address, not calling anything.

Competitor tutorials love to show you the syntax, but they skip the why. The address lets you store, pass, and invoke logic at runtime. That's what turns static C code into something dynamic. You don't need classes for polymorphism; you just need a pointer-sized value that points to executable instructions.

If you're debugging a crash and the callstack points to garbage, it's often because someone corrupted a function pointer. Know the address. Trust nothing.

// io.thecodeforge — c-cpp tutorial

#include <stdio.h>

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

int main() {
    // Function name without parentheses = address
    printf("greet lives at: %p\n", greet);
    
    // Same address via explicit & operator
    printf("greet address:  %p\n", &greet);
    
    void (*fn)() = greet;
    fn();   // call via pointer
    (*fn)();// explicit dereference — both work

    return 0;
}

Function Pointers in C++ — The Same Beast, Sharper Teeth

C++ inherits C's function pointers wholesale, but the language adds a layer of complexity that'll bite you if you're careless. Member function pointers? Different syntax, different cost. Lambdas? They can decay to function pointers, but only if they capture nothing — otherwise you're looking at std::function and heap allocations.

The core semantics haven't changed: a function pointer is still just an address. But C++ templates, overloads, and namespaces mean you can't always grab an address with just the bare name. You might need & explicitly to disambiguate an overloaded function. If you see "reference to overloaded function could not be resolved", that's your cue.

Bottom line: every trick you learned in C works here. The hazards come from C++ features that pretend to be simpler than they are. Test your assumptions with std::is_same or a static_assert — let the compiler tell you the truth.

// io.thecodeforge — c-cpp tutorial

#include <iostream>

struct Server {
    void start() { std::cout << "Server started\n"; }
    void stop()  { std::cout << "Server stopped\n"; }
};

using Action = void(Server::*)();

int main() {
    Action action = &Server::start;  // note & required
    Server svr;
    (svr.*action)();  // dot-star operator

    action = &Server::stop;
    (svr.*action)();

    return 0;
}

Function Pointers for Plugin Systems — Loading Unknown Code at Runtime

Static linking is for people who rebuild their entire product to add one feature. Real systems load functionality at runtime via dynamic libraries. Function pointers are the glue that makes this possible.

When you call dlopen() on a shared object, the OS hands you a handle. You then use dlsym() to pluck a function by name out of that binary blob. The symbol resolves to a memory address — exactly the same kind of address you'd get from &myFunction. Cast that to the correct function pointer type, and you're calling code that didn't exist when your program was compiled.

This is how game engines load mods, how editors support plug-ins, and how production servers swap logging backends without restart. The contract is simple: the plugin exposes a function with a known signature, usually int init(plugin_api* api). Your host calls it through a pointer. No headers, no recompilation. Just a void pointer cast and a handshake.

Memory management is your problem. The plugin's code stays in RAM until you call dlclose(). Keep the handle around if you plan to unload later — dangling function pointers are a crash just waiting for a holiday weekend.

// io.thecodeforge — c-cpp tutorial

#include <dlfcn.h>
#include <stdio.h>

typedef int (*plugin_init_t)(int version);

int main() {
    void* handle = dlopen("./simple_plugin.so", RTLD_NOW);
    if (!handle) { fprintf(stderr, "dlopen: %s\n", dlerror()); return 1; }

    plugin_init_t init = (plugin_init_t)dlsym(handle, "plugin_init");
    char* err = dlerror();
    if (err) { fprintf(stderr, "dlsym: %s\n", err); dlclose(handle); return 1; }

    int result = init(42);
    printf("Plugin returned: %d\n", result);
    dlclose(handle);
    return 0;
}

Polymorphism Without the vtable — Manual Dispatch in Embedded Systems

C++ vtables are a luxury. They cost memory per class, per instance. When your firmware has 2KB of RAM, you can't afford that. So you build polymorphism by hand with function pointers embedded in structs — one pointer per method, one table per object.

You define a struct with data and one function pointer per operation. A 'constructor' function fills those slots, then returns the struct. Each 'method' takes a pointer to that struct as its first argument — hello, this. The caller doesn't know whether it's talking to a UART driver or a SPI driver. It just calls dev->write(dev, buffer, len) through the pointer.

No casting, no inheritance, no virtual dispatch overhead. The function pointer is a direct jump. Compare that to a switch on device type, which the compiler may or may not optimize into a jump table. Manual dispatch always wins on worst-case latency. This is why every RTOS scheduler uses function pointers for task entry points.

The tradeoff: you type out the dispatch table yourself. No compiler-generated wrappers. But you also see exactly how much flash each virtual call costs. In constrained environments, that transparency is worth more than syntactic sugar.

// io.thecodeforge — c-cpp tutorial

#include <stdint.h>
#include <stdio.h>

struct Device {
    uint8_t id;
    int (*write)(struct Device* self, uint8_t byte);
};

int uart_write(struct Device* self, uint8_t byte) {
    printf("UART(%d) wrote 0x%02X\n", self->id, byte);
    return 0;
}

int spi_write(struct Device* self, uint8_t byte) {
    printf("SPI(%d) wrote 0x%02X\n", self->id, byte);
    return 0;
}

int main() {
    struct Device uart = {.id = 1, .write = uart_write};
    struct Device spi  = {.id = 2, .write = spi_write};
    uart.write(&uart, 0xAA);
    spi.write(&spi, 0x55);
    return 0;
}