PREV_LEC NEXT_LEC

Prerequisites

You should be comfortable with pointer declaration, the address-of operator, dereferencing, and the idea of a function call. If any of that feels shaky, revisit the earlier pointer lectures in this free C tutorial first. You need a C compiler such as GCC or Clang on Linux, or any embedded toolchain that can build a host test program.

What Is a Dangling Pointer in C?

Every local variable lives in a stack frame that is created when the function is called and thrown away when it returns. The memory is not erased. The stack pointer simply moves back, and the next function call reuses the same bytes for its own locals. A pointer that remembers the address of a dead local is therefore pointing at a slot that now belongs to someone else.

Dangling vs Wild vs NULL

Four Ways to Create a Dangling Pointer

• Returning the address of a local variable. The classic mistake: return &sample; inside a function.
• Storing a local’s address in a longer-lived pointer. A global, a struct field, or a registered callback context that outlives the function.
• Use after free. Calling free(p) and then reading *p, or freeing the same block through a second pointer.
• Leaving a block scope. A pointer to a variable declared inside an if or loop body used after the closing brace.

Fixing a Dangling Pointer in C: Four Safe Patterns

The program below shows three ways to return something useful from a function, plus the broken version for comparison. Save it as ep_dangling.c.

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

static int *read_bad(void)
{
    int sample = 512;
    return &sample;              /* address of a dead stack slot */
}

static int *read_static(void)
{
    static int last = 512;       /* lives for the whole program */
    return &last;
}

static int *read_heap(void)
{
    int *p = malloc(sizeof *p);
    if (p != NULL)
        *p = 768;
    return p;                    /* caller must free() */
}

static void read_into(int *out)
{
    *out = 1023;                 /* caller owns the storage */
}

int main(void)
{
    int *a = read_static();
    int *b = read_heap();
    int c = 0;

    read_into(&c);
    printf("static: %d  heap: %d  caller-owned: %d\n", *a, b ? *b : -1, c);
    free(b);
    (void)read_bad;
    return 0;
}

Build and Run

$ gcc -Wall -Wextra -std=c11 -o ep_dangling ep_dangling.c
ep_dangling.c: In function 'read_bad':
ep_dangling.c:7:12: warning: function returns address of local variable [-Wreturn-local-addr]
    7 |     return &sample;              /* address of a dead stack slot */
      |            ^~~~~~~
$ ./ep_dangling
static: 512  heap: 768  caller-owned: 1023

The compiler already caught read_bad() for us. Treat every warning with that text as a build failure. The other three functions are the safe patterns:

The Global Pointer Variant

The compiler does not always warn when the dangling address is stored in a global. Here is a quieter version, ep_dangling_bad.c:

#include <stdio.h>

static int *g_sensor;                /* file-scope pointer outlives every call */

static void bind_sensor(void)
{
    int reading = 42;
    g_sensor = &reading;             /* reading dies when we return */
}

int main(void)
{
    bind_sensor();
    printf("%d\n", *g_sensor);       /* use after the stack frame is gone */
    return 0;
}

Plain GCC compiles this without a peep. AddressSanitizer will not be fooled, provided you switch on its stack-use-after-return detection:

$ gcc -g -fsanitize=address -o dbad ep_dangling_bad.c
$ ASAN_OPTIONS=detect_stack_use_after_return=1 ./dbad
==308==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f9323b00020 ...
READ of size 4 at 0x7f9323b00020 thread T0
    #0 0x55c9e00bd3a5 in main ep_dangling_bad.c:14

Dangling Pointers in Embedded Systems

Firmware raises the stakes. A few real situations, all common in embedded C programming:

• Starting a DMA transfer from a local buffer. The function returns, the stack frame is reused, and the DMA engine keeps reading the old address. The bytes on the wire are nonsense.
• Registering a callback context. You pass &ctx where ctx is a local struct, then the callback fires later from an interrupt.
• Handing a message to an RTOS queue by pointer. If the sender’s local buffer is gone by the time the receiver runs, the receiver reads stale data.
• Freeing a buffer in one task while another still holds the pointer. Classic use-after-free across task boundaries.

On a microcontroller there is often no memory protection. A dangling write silently corrupts another variable instead of crashing, which makes the bug far harder to find than on a desktop.

Common Mistakes and Troubleshooting

Best Practices

• Compile with -Wall -Wextra and treat -Wreturn-local-addr as an error.
• Prefer caller-provided buffers. The caller decides the lifetime, so nothing can dangle.
• After free(p), immediately assign p = NULL.
• Never store the address of a local in anything that outlives the function: globals, structs, queues, callback contexts.
• Run your host-side unit tests under AddressSanitizer. Add static analysis such as cppcheck or clang-tidy to CI.
• In firmware, give DMA and queue buffers static storage with a clear owner.

Performance and Security Considerations

Caller-provided and static buffers cost nothing at run time, while heap allocation adds latency, fragmentation risk and a failure path you must handle. On the security side, returning a stack address is catalogued as CWE-562 and use after free as CWE-416. Attackers can sometimes steer what ends up in the reused memory, so these are not just reliability bugs.

Suggested Images

Summary and Key Takeaways

Conclusion

Pointer bugs rarely announce themselves. A dangling pointer in C compiles, runs, and often passes the first test, which is exactly why you need a habit of asking “who owns this memory and how long does it live?” every time an address crosses a function boundary. Practise the four safe patterns until they are automatic. In the next lecture we look at how pointers are passed to functions and why a copy of a pointer cannot move the original.

FAQ: Dangling Pointers in C

PREV_LEC NEXT_LEC