Integer Types, Signedness, and Overflow

A microcontroller register, a memory cell and a C integer variable all have a fixed number of bits. An $n$-bit unsigned value can represent $0$ to $2^n - 1$; an 8-bit uint8_t holds 0 to 255, a 16-bit uint16_t holds 0 to 65 535, a 32-bit uint32_t holds 0 to 4 294 967 295. There is no ninth bit to carry into. The natural picture is not a number line but a ring: one step past the top lands on the bottom.

↑ This step uses the figure at the top of the page.

For unsigned types C makes this exact. §6.3.1.3 of the standard says a value that does not fit is reduced modulo $2^n$, so

That is a definition, not an accident, and firmware relies on it. For signed types the same standard (§6.5 ¶5) says an unrepresentable result is undefined behaviour. The processor will still produce a bit pattern, and on every current architecture it is the two’s-complement wrap you would expect, but the language refuses to promise it. Lesson 6 explains why that refusal has teeth: the optimiser is allowed to delete code that could only matter if overflow occurred.

int is at least 16 bits; on 32-bit Cortex-M it is 32, on an 8-bit AVR it is 16. long is at least 32. char may be signed or unsigned depending on the compiler and target: it is signed on x86 GCC and unsigned on Arm GCC by default. Firmware that talks to hardware cannot live with “at least”. The header <stdint.h> (C11 §7.20) provides types whose width is part of the name:

Use these for anything that maps onto hardware: register contents, buffer bytes, sample values, protocol fields. Keep plain int for loop counters and arithmetic where the exact width does not matter. size_t is the unsigned type for sizes and array indices.

C never does arithmetic in types narrower than int. Before any operation, a uint8_t or int16_t operand is promoted to int (§6.3.1.1). This is why (uint8_t)0x80 << 1 is 0x100 and not 0: the shift happens in int. Only when the result is stored back into a uint8_t is it truncated to 0x00.

When a signed and an unsigned operand of the same rank meet, the usual arithmetic conversions (§6.3.1.8) convert the signed one to unsigned. Hence the classic trap:

int      a = -1;
unsigned b =  1;
if (a < b) { … }   /* never taken: -1 becomes 4294967295u */

The comparison is done in unsigned int, where −1 wraps to the maximum value. Most compilers warn about signed/unsigned comparison; the fix is to keep both operands the same signedness, and the habit is to keep quantities that can never be negative unsigned from the start.

A free-running 16-bit hardware timer counts up at 1 MHz and wraps from 65 535 to 0. Firmware records start = 65 000, waits, and later reads now = 1 200. How long elapsed?

Naively $1200 - 65000 = -63800$: wrong, and in a signed 16-bit type it would also overflow. In uint16_t arithmetic the subtraction wraps by definition:

$$(1200 - 65000) \bmod 65536 = 1736$$

So 1 736 µs elapsed, which is correct: 536 ticks to reach the wrap, then 1 200 more. The single rule that makes this work is subtract in the same unsigned width as the counter. In C the subtraction happens in int after promotion, so cast the result back: (uint16_t)(now - start). This works for any elapsed time shorter than one full period (65.536 ms here); longer intervals are ambiguous, and you need a wider counter or an overflow interrupt that counts the wraps.

The same reasoning tells you when a sum will not fit. Averaging 100 ADC samples of up to 4 095 each gives a maximum sum of 409 500, which exceeds 65 535: accumulate in uint32_t, not uint16_t, or the average will be silently wrong for bright inputs.