Embedded C Pitfalls: Undefined Behavior and Memory Traps

Quickstart

If you only do a few things, do these. They’re the fastest way to remove the “mystery bug” class of failures: hard faults, silent corruption, and timing-dependent heisenbugs.

Overview

C gives you direct control over memory and hardware—but the language also leaves room for behaviors that are not defined by the standard. On microcontrollers, those edge cases show up as hard faults, corrupted peripherals, or timing glitches that disappear when you add a printf.

This isn’t a “write MISRA-compliant code everywhere” manifesto. It’s a pragmatic guide: keep code fast and small, but remove the common footguns that waste entire evenings.

Core concepts

1) Undefined vs unspecified vs implementation-defined

The C standard uses different categories for “the compiler can do different things here”: understanding the difference helps you decide when a warning is harmless vs dangerous.

2) Embedded memory is not “one flat RAM”

Microcontrollers often have multiple memory regions with different rules: flash vs SRAM, DMA-accessible RAM, cacheable vs non-cacheable, tightly-coupled memory, and memory-mapped peripherals. Bugs happen when code assumes desktop-like behavior.

3) Integers, promotions, and overflow

In Embedded C, integer bugs are common because we mix bit operations, register fields, protocol parsing, and different-width types. Two rules help:

• Signed overflow is UB. If you might overflow, use a wider type or explicit saturating logic.
• Small integer types promote. uint8_t and int16_t often promote to int in expressions.

4) Concurrency: interrupts are threads with sharp edges

Many firmware bugs are race conditions between main code and ISRs (or between tasks in an RTOS). volatile helps with visibility to the compiler, but it does not make multi-byte updates atomic, and it does not create safe ordering by itself.

Step-by-step

Here’s a workflow that catches the majority of embedded C pitfalls early. You can adopt it incrementally: start with flags and guards, then add the stronger checks as your firmware grows.

Step 1 — Harden your build: warnings, LTO awareness, and debug settings

The compiler is your best bug detector. Make it strict, and keep a separate “host test” build so you can use sanitizers. The goal is not to enable every flag forever, but to have a default that makes risky code uncomfortable to write.

# Toolchain-hardening starter (adapt paths/MCU flags to your project)

# 1) MCU build (arm-none-eabi-gcc example)
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -ffunction-sections -fdata-sections \
  -Wall -Wextra -Werror -Wshadow -Wconversion -Wsign-conversion -Wformat=2 \
  -Wnull-dereference -Wdouble-promotion -Wundef \
  -fno-common -fno-strict-aliasing \
  -Og -g3 \
  -c src/main.c -o build/main.o

arm-none-eabi-gcc -Tlinker.ld -Wl,--gc-sections -Wl,-Map=build/firmware.map \
  build/main.o -o build/firmware.elf

arm-none-eabi-size build/firmware.elf

# 2) Host build for tests (clang + sanitizers)
# Useful for parsers/protocol/state machines that run on both MCU and PC.
clang -std=c11 -O1 -g \
  -fsanitize=address,undefined -fno-omit-frame-pointer \
  -Wall -Wextra -Werror \
  tests/test_protocol.c src/protocol.c -o build/test_protocol

./build/test_protocol

Step 2 — Know your memory budgets: stack, heap, and static

When memory is tight, “it works on my board” can be misleading. A different compile flag, a new ISR, or a larger packet can change stack usage and trigger corruption. Treat memory like a budget you measure, not a guess you hope is fine.

Step 3 — Write bounds-first code for buffers and protocol parsing

Many embedded systems parse bytes: UART frames, SPI registers, BLE packets, custom protocols. Parsing is a hotspot for buffer overflows, alignment issues, and endianness mistakes. A good pattern is: check bounds, then parse. Don’t cast raw bytes into structs unless you control packing and alignment (and even then, be cautious).

#include <stdint.h>
#include <stddef.h>
#include <stdbool.h>

typedef struct {
  uint16_t msg_type;
  uint32_t value;
} msg_t;

static bool read_u16_be(const uint8_t *buf, size_t len, size_t *off, uint16_t *out) {
  if (*off + 2u > len) return false;
  uint16_t hi = (uint16_t)buf[*off + 0u];
  uint16_t lo = (uint16_t)buf[*off + 1u];
  *out = (uint16_t)((hi << 8) | lo);
  *off += 2u;
  return true;
}

static bool read_u32_be(const uint8_t *buf, size_t len, size_t *off, uint32_t *out) {
  if (*off + 4u > len) return false;
  uint32_t b0 = (uint32_t)buf[*off + 0u];
  uint32_t b1 = (uint32_t)buf[*off + 1u];
  uint32_t b2 = (uint32_t)buf[*off + 2u];
  uint32_t b3 = (uint32_t)buf[*off + 3u];
  *out = (b0 << 24) | (b1 << 16) | (b2 << 8) | b3;
  *off += 4u;
  return true;
}

bool parse_msg(const uint8_t *buf, size_t len, msg_t *out) {
  if (buf == NULL || out == NULL) return false;

  size_t off = 0u;
  uint16_t type = 0u;
  uint32_t val  = 0u;

  if (!read_u16_be(buf, len, &off, &type)) return false;
  if (!read_u32_be(buf, len, &off, &val))  return false;

  out->msg_type = type;
  out->value = val;
  return true;
}

Step 4 — Treat MMIO registers differently than RAM

Peripheral registers are not normal variables. Reads can have side effects (e.g., clearing an interrupt flag), and writes may require specific ordering. Use volatile for MMIO access, but avoid scattering raw register math across the codebase. Wrap it with small, readable helpers.

Step 5 — Automate memory and quality checks in CI

You don’t need heavy process, but you do need consistency. Two cheap checks go a long way: (1) fail builds on warnings and (2) fail builds when memory budgets are exceeded. Linker map files are perfect for this because they reflect real layout after linking.

#!/usr/bin/env python3
import re
import subprocess
import sys

# Adjust budgets to your target (bytes)
FLASH_BUDGET = 512 * 1024   # 512 KiB
RAM_BUDGET   = 128 * 1024   # 128 KiB

ELF = sys.argv[1] if len(sys.argv) > 1 else "build/firmware.elf"

def run_size(elf_path: str) -> str:
  # GNU size output typically: text data bss dec hex filename
  out = subprocess.check_output(["arm-none-eabi-size", elf_path], text=True)
  return out.strip()

def parse_size(output: str):
  lines = output.splitlines()
  if len(lines) < 2:
    raise ValueError("Unexpected size output")
  cols = re.split(r"\s+", lines[1].strip())
  if len(cols) < 4:
    raise ValueError("Unexpected size columns")
  text = int(cols[0])
  data = int(cols[1])
  bss  = int(cols[2])
  flash = text + data
  ram   = data + bss
  return flash, ram, text, data, bss

def main():
  try:
    out = run_size(ELF)
    flash, ram, text, data, bss = parse_size(out)
  except Exception as e:
    print(f"[budget] ERROR: {e}")
    return 2

  print(f"[budget] ELF: {ELF}")
  print(f"[budget] FLASH (text+data): {flash} bytes (budget {FLASH_BUDGET})")
  print(f"[budget] RAM   (data+bss):   {ram} bytes (budget {RAM_BUDGET})")

  ok = True
  if flash > FLASH_BUDGET:
    print("[budget] FAIL: flash budget exceeded")
    ok = False
  if ram > RAM_BUDGET:
    print("[budget] FAIL: ram budget exceeded")
    ok = False

  return 0 if ok else 1

if __name__ == "__main__":
  raise SystemExit(main())

Common mistakes

These are the Embedded C pitfalls that show up again and again in code reviews and field failures. Each item includes a concrete fix you can apply today.

FAQ

What’s the simplest definition of undefined behavior in embedded C?

Undefined behavior means the C standard doesn’t define what happens, and the compiler is free to assume it never occurs. In embedded systems, that often looks like code that works in debug but breaks in release, or failures far away from the bug.

Does volatile make code safe across interrupts or RTOS tasks?

No. Volatile affects optimization, not correctness. It can help ensure a variable is re-read from memory, which is necessary for MMIO registers and some ISR-shared flags, but it does not make multi-byte updates atomic and it does not replace critical sections, atomics, or message passing.

Should I avoid dynamic allocation (malloc) in firmware?

For many systems, yes—or at least restrict it. If you must allocate, allocate at startup and avoid allocate/free during steady state. Fragmentation and failure handling are where embedded systems tend to break.

How do I prevent stack overflow on a microcontroller?

Measure and guard. Add a stack canary/high-water mark, keep large buffers out of locals, and watch deep call chains (especially with callbacks and logging). If you run an RTOS, measure per-task stacks and tune with real workloads.

When should I disable strict aliasing?

If your codebase (or third-party code) relies on type-punning that violates aliasing rules, the safest option is to fix the code (use memcpy or well-defined access patterns). If that’s not realistic immediately, -fno-strict-aliasing is a pragmatic mitigation to reduce optimizer-induced miscompilations.

What’s the fastest way to catch memory bugs without fancy tools on the MCU?

Add lightweight checks: stack canaries, guard bytes around critical buffers, assert invariants, and log reset reasons. Combine that with a host test build using sanitizers for code that can run on a PC (parsers, state machines, math).

Cheatsheet

Use this as a pre-merge checklist and a “why is this firmware weird?” triage list.

Wrap-up

The fastest way to write safer firmware is not “more testing” in the abstract—it’s removing the bug classes that create non-determinism: undefined behavior, silent truncation, and memory corruption. Start with strict builds, then add a small set of runtime guards and host sanitizer tests. You’ll spend less time chasing ghosts and more time shipping features.

If you want to go deeper, the “Related posts” section below pairs nicely with this topic: communication protocols, OTA updates, and clean wiring all benefit from the same “make failures loud” mindset.

Related posts

• OTA Updates for IoT: The Safe Way to Ship Firmware
• ESP32 Starter Guide: GPIO, Wi-Fi, and Real Projects
• Arduino to Prototyping: Sensors, Actuators, and Clean Wiring
• Raspberry Pi as a Home Server: Safe Setup and Use Cases
• UART vs I2C vs SPI: Which Protocol to Use and Why
• MQTT Explained: The Message Bus Behind Many IoT Systems