Structures, Alignment, and Data Layout

The C standard promises two things about a struct (§6.7.2.1): members are laid out in declaration order at increasing addresses, and the compiler may insert unnamed padding bytes between them and after the last one. It does not say how much. The amount comes from the target’s ABI (application binary interface), which sets an alignment for each basic type: an address that a value of that type must be a multiple of.

On 32-bit Arm (AAPCS32 §5.1) the alignments are the “natural” ones: a char can be anywhere, a uint16_t must be at an even address, a uint32_t at a multiple of 4, a uint64_t at a multiple of 8. Each member is placed at the next offset that satisfies its own alignment. If the previous member ends at byte $e$ and the next member’s alignment is $a$, the next offset is $e$ rounded up to a multiple of $a$:

$$\text{offset} = \left\lceil \frac{e}{a} \right\rceil \times a$$

The struct as a whole takes the largest alignment among its members, $A$, and its size is rounded up to a multiple of $A$ in the same way, so that consecutive elements of an array of the struct are all correctly aligned.

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

The default order in the figure, char a; int b; char c;, puts a at offset 0, then needs three padding bytes so that b starts at 4, places c at 8, and pads to 12 so the next array element’s b lands on a multiple of 4. Six bytes of data, six of padding. Reorder to int b; char a; char c; and the same members take 8. Nothing changed but the declaration order; the rule for the compiler is fixed, so the layout is yours to choose.

offsetof(struct type, member) from <stddef.h> gives the offset the compiler actually chose. Use it, together with sizeof, in a _Static_assert whenever a layout matters: the assert documents the assumption and fails the build on a target where it does not hold.

Alignment exists because a data bus fetches a naturally aligned word in one operation. A 32-bit value starting at an odd address straddles two words; the hardware must either do two fetches and stitch the halves together, or refuse.

Both happen on Arm, depending on the core. Armv7-M (Cortex-M3, M4, M7) supports unaligned single-word and halfword loads and stores for ordinary LDR/STR, at the cost of extra bus cycles, but not for multiple-register or exclusive instructions, and the UNALIGN_TRP bit can be set to make every unaligned access fault instead (DDI 0403 §A3.2.1). Armv6-M (Cortex-M0, M0+) does not support unaligned data access at all: the access takes a HardFault. The same C source therefore runs on one chip and crashes on another, which is the reason to respect alignment rather than rely on the forgiving core you happen to be using.

unsigned mode : 2; declares a bit-field, and it is tempting to describe a hardware register as a struct of bit-fields. The standard makes almost everything about their layout implementation-defined (§6.7.2.1 ¶11): which end of the word the first field starts at, whether fields cross a word boundary, what access width the compiler uses. Two compilers can lay the same declaration out differently, and the access width matters to hardware. Use masks and shifts (lesson 1) for registers; keep bit-fields for compact in-memory flags where the layout is nobody else’s business.

A union places all its members at offset 0 and is as large as its largest member. Reading a member other than the one last written reinterprets the bytes, which C permits with implementation-defined results; it is the accepted way to view a float as a uint32_t. It is not a way to reinterpret a peripheral register, whose access width and side effects are fixed by hardware.

The header from the opening: uint8_t type; uint32_t timestamp; uint16_t length;.

Declared in that order (AAPCS32): type at 0, three bytes of padding, timestamp at 4, length at 8, two bytes of tail padding, sizeof = 12. Alignment 4.

Reordered to uint32_t timestamp; uint16_t length; uint8_t type;: offsets 0, 4, 6, one byte of tail padding, sizeof = 8. A log of 1 000 headers shrinks from 12 000 to 8 000 bytes with no change in behaviour.

Sent over a wire: neither layout is a protocol. Even the 8-byte version carries a padding byte of unspecified content and stores the timestamp little-endian, so a big-endian receiver, or a receiver whose compiler chose different padding, decodes it wrongly. The reliable approach is to define the wire format as a sequence of bytes and serialise explicitly:

out[0] = h->type;
out[1] = (uint8_t)(h->timestamp >> 24);   /* big-endian on the wire */
out[2] = (uint8_t)(h->timestamp >> 16);
out[3] = (uint8_t)(h->timestamp >> 8);
out[4] = (uint8_t)(h->timestamp);
out[5] = (uint8_t)(h->length >> 8);
out[6] = (uint8_t)(h->length);

Seven bytes, no padding, an order that both sides agree on, and the compiler’s layout decisions never leave the chip.