> A bug in C caused an alignment issue? That's pretty surprising to me. That should be abstracted from the programmer. If it was written in assembly, it makes sense, though.

Memory alignment in C is most definitely not abstracted from the programmer. The compiler does add some padding to fit alignments but they can either work for you or against you. 98% of the time it works the way you want it but when it goes wrong, it's going to be a hard problem to debug. So it's absolutely critical for a C programmer to know a thing or two about alignment, especially the cases where the compiler attempts to fix it for you.

Examples of alignments that can have a performance effect or in some scenarios (multithreading, kernel programming) may affect the correctness of the program: 4 bytes (word size), 8 bytes (64b pointer size), 16 bytes (SSE/NEON SIMD register size), 32 bytes (ARM cache line size, AVX SIMD register), 128 bytes (ARM and x86 cache line size), 4k (ARM and x86 page size). Add relevant figures for any other target archs you're dealing with.

When doing GPU work (using glMapBufferRange or something), there are other alignments to care about and they may be GPU-specific. Aligning everything to 2^N can never hurt.

Not that hard. Apply improper member alignment via aligned/packed attributes, or hit a compiler bug, or just do something funny, and then execute code that requires specific alignment, like, say, an SSE code path in a PNG decoder that expects natural alignment.