Embedded C

Data Types & Integer Overflow

The C standard doesn't guarantee an int is 32 bits — only that it's at least 16. On a desktop that ambiguity almost never bites anyone; on embedded, where the same codebase might target an 8-bit AVR and a 32-bit Cortex-M, it's exactly the kind of thing that silently changes behavior between platforms. This page covers what the types actually guarantee, why unsigned shows up constantly in embedded code, and what actually happens — bit for bit — when a value overflows.

Why stdint.h exists

char, short, int, long, and long long each only guarantee a minimum width — the standard leaves the exact size up to the compiler and target architecture. An int is 16 bits on some small microcontroller toolchains and 32 bits on almost everything else; writing code that assumes one or the other is silently non-portable. <stdint.h> fixes this with fixed-width types that mean exactly what they say on every conforming compiler:

Any embedded codebase that talks to hardware registers or a wire protocol should reach for these instead of int/ unsigned — a struct sent over CAN or read from an I2C register genuinely has a fixed bit width, and the type should say so explicitly rather than relying on whatever int happens to mean on this particular toolchain.

Signed vs. unsigned representation

Both a signed and unsigned 8-bit integer are 256 possible bit patterns — the difference is purely how those patterns are interpreted. Unsigned reads the bits directly as a magnitude: 0000 0000 through 1111 1111 is 0 through 255. Signed integers use two's complement: the top bit becomes a sign bit, so the same 256 patterns split into -128 through 127 instead — half the positive range, in exchange for representing negative numbers at all.

Why embedded code reaches for uint

• The value is inherently non-negative — a buffer length, a pin number, a byte count, or a raw register value can never logically be negative; declaring it unsigned documents that intent and lets a reviewer (or the compiler, with warnings on) catch a bug that would let it go negative.
• Bitwise operations behave predictably — shifting, masking, and combining raw bits with &/|/^ is well-defined on unsigned types. A right-shift of a negative signed value is implementation-defined in C — not guaranteed to be the arithmetic shift most people assume — which makes signed types a real hazard for register-level bit manipulation.
• Full range for the same memory — when a value truly can't be negative, unsigned doubles the usable range in the same number of bits — meaningful when every byte of RAM is budgeted.
• Hardware registers are unsigned bit patterns — a peripheral register doesn't have a sign; representing it as uint32_t is the accurate mapping to what the hardware actually is, not a style preference.

What rollover actually is

Unsigned arithmetic in C is defined to wrap modulo 2ⁿ — this is not a bug or undefined behavior, it's exactly what the standard guarantees will happen. Adding 1 to the maximum value of a uint8_t doesn't error, doesn't saturate — it silently becomes 0.

The bug this actually causes in the field almost never looks like the diagram above — it looks like an unsigned subtraction going the wrong direction:

uint32_t deadline = start_time + TIMEOUT_MS;
uint32_t remaining = deadline - now();

// if now() has already passed deadline, "remaining" doesn't go negative —
// there's no negative in unsigned arithmetic. It wraps to a number near
// UINT32_MAX, and code checking "if (remaining > 0) keep_waiting();"
// concludes there's still billions of milliseconds left to wait.

Integer promotion and the comparison trap

Small types are promoted to int before most operations — a uint8_t in an expression is temporarily treated as an int, which is usually invisible but occasionally matters. Far more dangerous: comparing a signed value to an unsigned one silently converts the signed value to unsigned first.

int x = -1;
unsigned int y = 0;
if (x > y) {
    // this branch RUNS — x is converted to UINT_MAX before comparing,
    // and UINT_MAX really is greater than 0
}

Real-world applications

• Register-width matching — writing an 8-bit peripheral register with a uint8_t instead of int prevents a value silently truncated by the hardware from ever looking correct in the C code that wrote it.
• Protocol field widths — a I2C/SPI frame field with a fixed bit width maps directly onto a stdint.h type — the type declares the wire format instead of leaving it implicit.
• Buffer index sizing — sizing a loop counter or array index to match the actual buffer size (rather than defaulting to int) avoids the classic off-by-one/overflow class of bug in a fixed-size ring buffer (see Stacks, Queues & Ring Buffers).

Gotchas