How does the Go compiler decide a struct type's alignment and total size?

## The three quantities For any Go type the compiler knows a size and an alignment; for a struct it also knows an offset per field. The three `unsafe` constants expose exactly these: `unsafe.Sizeof(v)`, `unsafe.Alignof(v)` and `unsafe.Offsetof(s.f)`. They evaluate at compile time to untyped constants of type `uintptr`, so you can even use them in a constant expression or an array length. ## The layout algorithm 1. Start the running offset at 0. 2. For each field, in **declaration order**, round the running offset up to the next multiple of that field's alignment. The bytes skipped are padding. 3. Place the field there and advance the running offset by the field's size. 4. When the fields are done, set the struct's alignment to the largest field alignment (1 for a struct with no fields), and round the running offset up to a multiple of it. That final rounding is tail padding, and the result is the struct's size. On a 64-bit target the base alignments are: 1 for `bool`, `int8`, `uint8`; 2 for `int16`, `uint16`; 4 for `int32`, `uint32`, `float32`; and 8 for `int64`, `uint64`, `float64`, `int`, `uint`, `uintptr` and every pointer. Eight is the ceiling in the gc toolchain — no Go type demands more, so no struct is ever aligned to 16 or 32. A fixed-width header declared in schema order shows all four steps at once: ``` type header struct { version uint8 // offset 0 flags uint32 // offset 4 — three bytes of padding at 1..3 sequence uint64 // offset 8 kind uint8 // offset 16 — seven bytes of tail padding at 17..23 } // Alignof == 8, Sizeof == 24, but the fields carry only 14 bytes. ``` Regrouped as `sequence`, `flags`, `version`, `kind` the same header is 16 bytes: `sequence` at 0, `flags` at 8, `version` at 12, `kind` at 13, and one run of tail padding to 16. ## Composite fields - **An array** has the alignment of its element and a size of `len × elemSize` — arrays are never padded between elements, because the element size is already a multiple of the element alignment. - **A nested struct** contributes its own alignment upward. Embedding a struct whose widest field is an `int64` makes the outer struct 8-aligned even if all of its own fields are bytes. - **An empty struct**, `struct{}`, has size 0 and alignment 1. It costs nothing as a map value or a channel element. ## Zero size at the end is a special case A zero-sized field is free in the middle of a struct but not at the end. If a non-empty struct's last field has size 0, the compiler adds one byte of padding, which then rounds up to the alignment. The reason is pointer safety: taking the address of that final field must not produce a pointer to the next object in the heap, which would keep an unrelated allocation alive. So `struct{ n int64; _ struct{} }` is 16 bytes while `struct{ _ struct{}; n int64 }` is 8 — the same two members, one byte of difference in principle, eight in practice. ## Targets change the numbers Size and alignment are properties of a compilation, not of the source. On a 32-bit target `int`, `uint`, `uintptr` and pointers are four bytes wide, so a struct of two pointers is 8 bytes there and 16 on amd64. The 64-bit scalar types are the interesting case: on 32-bit x86 and 32-bit ARM the alignment of an `int64` field is 4, not 8, so a 64-bit field can land on a four-byte boundary. That is precisely why the `sync/atomic` documentation carries a caveat about arranging 64-bit alignment yourself on those platforms. Never hard-code a size you measured on your laptop into logic that has to run elsewhere; compute it with `unsafe.Sizeof` or assert it in a test that runs on each target you build for. ## Why the rules are worth knowing They turn a vague feeling that structs are bigger than they look into arithmetic you can do at a whiteboard, and they tell you which lever actually moves the number: the order of the fields and the width of their types. They also mark the limits — you cannot make a struct 14 bytes when its alignment is 8, no matter how you shuffle the fields, because the size must be a multiple of 8.