over-alignment
Every type has a natural alignment that the compiler guarantees automatically — say 8 bytes for a double. Over-alignment is when you ask for an alignment STRONGER than that natural requirement, for example forcing a buffer onto a 64-byte boundary even though its elements only need 8. The term simply names 'an alignment bigger than the type would normally demand'.
You request over-alignment with alignas, as in alignas(64) struct counters c, which pads and positions the object so its address is a multiple of 64. The standard calls any alignment larger than alignof(max_align_t) an EXTENDED alignment, and it is implementation-defined whether a given extended alignment is supported. For dynamic memory, plain malloc only promises alignment suitable for any ordinary type, so to heap-allocate an over-aligned object you use aligned_alloc(alignment, size) (C11) or posix_memalign, and you must free it with free().
It matters in two big places: avoiding false sharing by putting hot per-thread data on separate cache lines, and meeting hardware demands of SIMD vector loads or DMA engines that fault on misaligned addresses. The honest caveats: over-alignment wastes some memory in padding, malloc'd memory is NOT guaranteed over-aligned (use aligned_alloc), and aligned_alloc requires the size to be a multiple of the alignment on many implementations.
#include <stdlib.h> // heap-allocate a 64-byte-aligned 4 KiB block: void *p = aligned_alloc(64, 4096); // size is a multiple of 64 // ... use p ... free(p); // still freed with free()
malloc does not promise over-alignment; aligned_alloc gives a block on a chosen power-of-two boundary, freed normally.
Whether a particular extended (over-) alignment is supported is implementation-defined, and ordinary malloc gives no over-alignment guarantee — use aligned_alloc and still free() the result.