Structures and Unions in C Explained — Memory, Use Cases and Pitfalls

Every real-world program deals with grouped data. A game needs to track a player's name, health, score, and position together. A network driver needs to interpret the same 4 bytes as either an IPv4 address, a 32-bit integer, or four individual octets depending on context. Trying to manage all of that with loose individual variables is like trying to run a hospital with sticky notes instead of patient records — technically possible, catastrophically unmanageable. Structures and unions are C's answer to that chaos.

The problem they solve is fundamentally about organisation and memory semantics. A struct gives you a custom data type that bundles related variables under one name, each with its own guaranteed memory slot. A union takes that idea and flips the memory model — all members share the same block of memory, which means you get type-reinterpretation and memory efficiency at the cost of only being able to use one member at a time. These aren't just syntax features; they're tools that let you model the real world accurately in code.

By the end of this article you'll understand exactly how struct and union memory layouts work, when each is the right tool, how to combine them for practical patterns like tagged unions, and the exact mistakes that trip up even experienced C developers. You'll also be able to confidently answer the interview questions that separate candidates who've read about C from those who've actually used it.

Structs: Grouping Related Data With Dedicated Memory

A struct (short for structure) lets you define a composite data type — a single named container that holds multiple members, each with its own type. The compiler allocates memory for every member independently, so all fields exist simultaneously and can be read or written in any order.

The real power isn't just convenience — it's that a struct becomes a first-class type. You can pass it to functions, return it, put it in arrays, and point to it. This lets you model domain concepts directly. A 'Player' struct isn't just three variables that happen to be related; it's a single coherent entity your code can reason about.

Under the hood, struct members are laid out sequentially in memory, but the compiler is allowed to insert padding bytes between members to satisfy alignment requirements of the target CPU. This means sizeof(struct Player) might be larger than you expect, and it's the first thing you need to internalise before you do anything serious with structs in systems programming or binary file I/O.

Use structs whenever you have data that naturally belongs together and needs all its fields present at the same time — think database records, configuration objects, game entities, or network packet headers.

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

/**
 * io.thecodeforge demonstration: Professional Struct Usage
 */
typedef struct {
    char  username[32];  
    int   health;        
    float position_x;   
    float position_y;   
    int   score;         
} Player;

void print_player_status(Player p) {
    printf("--- Player Status ---\n");
    printf("Username : %s\n",  p.username);
    printf("Health   : %d\n",  p.health);
    printf("Position : (%.1f, %.1f)\n", p.position_x, p.position_y);
    printf("Score    : %d\n",  p.score);
}

void apply_damage(Player *p, int damage_amount) {
    if (p == NULL) return;
    p->health -= damage_amount;
    if (p->health < 0) p->health = 0;
}

int main(void) {
    Player hero = {
        .username   = "Aria_Stormblade",
        .health     = 100,
        .position_x = 12.5f,
        .position_y = 7.0f,
        .score      = 0
    };

    apply_damage(&hero, 35);
    hero.score += 500;
    print_player_status(hero);

    printf("\nTotal struct footprint: %zu bytes\n", sizeof(Player));
    return 0;
}

Memory Layout and Padding — Why sizeof Surprises You

This is the section most tutorials skip, and it's the one that causes the most real-world bugs. CPUs are picky about alignment — a 4-byte int wants to live at a memory address that's divisible by 4. A double wants an address divisible by 8. When the compiler lays out struct members sequentially, it inserts invisible padding bytes to honour these constraints.

Consider a struct with a char (1 byte) followed by an int (4 bytes). The char sits at offset 0, but the int needs to start at offset 4 — so 3 bytes of padding are inserted silently. The struct's total size also gets padded at the end so that arrays of the struct keep every element aligned.

This matters enormously in three situations: serialising structs to binary files or network packets (padding bytes contain garbage), computing offsets manually, and squeezing memory in embedded systems. The fix in the first two cases is either reordering your members largest-to-smallest (which often eliminates padding naturally) or using __attribute__((packed)) / #pragma pack — but only when you truly need it, because unaligned access is slower on most architectures and outright illegal on some.

#include <stdio.h>
#include <stddef.h> 

typedef struct {
    char   is_active;    // 1 byte
    // 3 bytes padding
    int    user_id;      // 4 bytes
    char   grade;        // 1 byte
    // 7 bytes padding
    double score;        // 8 bytes
} StudentUnoptimised;    // 24 bytes total

typedef struct {
    double score;        // 8 bytes
    int    user_id;      // 4 bytes
    char   is_active;    // 1 byte
    char   grade;        // 1 byte
    // 2 bytes padding at end
} StudentOptimised;      // 16 bytes total

int main(void) {
    printf("Unoptimised size: %zu bytes\n", sizeof(StudentUnoptimised));
    printf("Optimised size:   %zu bytes\n", sizeof(StudentOptimised));
    printf("Memory saved:     %zu bytes per instance\n", 
           sizeof(StudentUnoptimised) - sizeof(StudentOptimised));
    return 0;
}

Unions: One Memory Location, Many Interpretations

A union looks syntactically identical to a struct but operates on a completely different principle: all members share the same starting address and the same block of memory. The union's size equals the size of its largest member. Writing to one member and reading from a different one reinterprets the raw bytes — which is either a powerful tool or a disaster, depending on whether you do it intentionally.

The classic legitimate use cases are: type-punning (reinterpreting the raw bytes of a float as a uint32_t, for example), memory-mapped hardware registers where the same address has different meanings, and building tagged unions (also called discriminated unions) where a type tag tells you which member is currently valid.

The illegitimate use — writing member A and reading member B expecting a meaningful 'conversion' — is undefined behaviour in C for most type combinations. The exception is char/unsigned char, which you're always allowed to use to inspect raw bytes.

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

typedef union {
    uint32_t as_integer;
    uint8_t  octets[4];
} IPv4Address;

typedef enum { TEMP, PRESS, HUMID } SensorType;

typedef struct {
    SensorType type;
    union {
        float   celsius;
        float   hpa;
        uint8_t percent;
    } reading;
} SensorReading;

int main(void) {
    IPv4Address addr;
    addr.as_integer = 0xC0A80101; // 192.168.1.1

    printf("IP: %u.%u.%u.%u\n", addr.octets[3], addr.octets[2], addr.octets[1], addr.octets[0]);
    
    SensorReading s = { .type = TEMP, .reading.celsius = 25.5f };
    printf("Reading: %.1f C\n", s.reading.celsius);
    
    return 0;
}

Combining Structs and Unions — Building Real Data Structures

In production C code, structs and unions almost always appear together. A pure union with no tag is hard to use safely. A struct with no unions is sometimes wasteful. Combine them and you get expressive, memory-efficient data models.

A common real-world pattern is a variant record — a struct that represents one of several possible entity types, where the correct interpretation depends on a discriminator field. This pattern powers everything from protocol buffer implementations to expression trees in compilers.

Another key pattern is bit fields inside structs, which let you pack boolean flags and small integers into individual bits rather than full bytes. This is critical in embedded systems where a microcontroller might have only 2KB of RAM.

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

typedef enum { NODE_NUM, NODE_OP } NodeType;

typedef struct ExprNode ExprNode;
struct ExprNode {
    NodeType type;
    union {
        int val;
        struct {
            char op;
            ExprNode *left;
            ExprNode *right;
        } bin;
    } data;
};

ExprNode* make_num(int n) {
    ExprNode *node = malloc(sizeof(ExprNode));
    node->type = NODE_NUM; node->data.val = n;
    return node;
}

int eval(ExprNode *n) {
    if (n->type == NODE_NUM) return n->data.val;
    int l = eval(n->data.bin.left), r = eval(n->data.bin.right);
    return (n->data.bin.op == '+') ? l + r : l * r;
}

int main(void) {
    // (2 + 3) * 4
    ExprNode *add = malloc(sizeof(ExprNode));
    add->type = NODE_OP; add->data.bin.op = '+';
    add->data.bin.left = make_num(2); add->data.bin.right = make_num(3);

    ExprNode *root = malloc(sizeof(ExprNode));
    root->type = NODE_OP; root->data.bin.op = '*';
    root->data.bin.left = add; root->data.bin.right = make_num(4);

    printf("Result: %d\n", eval(root));
    return 0;
}

Frequently Asked Questions