I had a bug that took me a while to track down. The problem\nwas type punning. A pointer cast worked fine at -O0 and\nsilently broke at -O2. The C vs C++ distinction here is genuinely\ntreacherous, and most blog posts on the topic get it wrong.
Type punning is interpreting memory as different types between reads\nand writes. It’s essential for serialisation, network protocols, and\nlow-level hardware access.
\nThe problem is that “works in practice” and\n“has defined behaviour” are different things.
\nIn C, the safe ways to type pun are union and memcpy. Pointer casts are technically undefined behavior under strict aliasing rules, even though they work on every compiler you’ll encounter.
A union lets you write as one type and read as another.\nThis is defined behavior in C:
\n`union {\n float f;\n uint32_t bits;\n} pun;
\npun.f = 3.14f;\nuint32_t exp = (pun.bits >> 23) & 0xff; // extract IEEE-754 exponent\n`
\nThis also works beautifully for pulling apart structs:
\n`union {\n struct color { float r, g, b, a; } c;\n float as_array[4];\n} u;
\nu.c = (struct color){ .r = 1, .a = 1 };\nfloat a = u.as_array[3];\n`
\nIf you don’t want a union, memcpy is safe and the compiler will optimise it to a register move:
float f = 3.14f;\nint i;\nmemcpy(&i, &f, sizeof(f)); // defined behavior, compiles to a single instruction\n
This compiles, runs, and gives you the “right” answer on every platform:
\nfloat f = 3.14f;\nint *p = (int *)&f;\nint i = *p;\n
It’s also undefined behavior. The strict aliasing rule says an object shall only be accessed through an lvalue of its effective type, a qualified version of it, or a character type. A pointer cast to an unrelated type violates this.
\nIn C, types are a way to interpret memory. In C++, types are first-class citizens — the compiler is allowed to assume that different types never alias each other.
\nThis has concrete consequences. Consider:
\n`struct c {\n uint32_t a;\n uint32_t b;\n};
\nuint32_t bar(uint64_t *u64, struct c *c) {\n if (c->a == 2) {\n *u64 = 4;\n }
\nif (c->a == 2) {\n return c->a;\n}\n\nreturn c->b;}
\nint main() {\n struct c c = { 2, 3 };\n return bar((uint64_t *) &c, &c);\n}\n`
\nWith GCC or Clang at -O2, this returns 2. At -O1 or below, it returns 0. The compiler sees that u64 is uint64_t* and c is struct c* — different types — so it assumes they don’t alias. The second c->a == 2 check gets optimised away based on the assumption that writing *u64 = 4 can’t change c->a. This is technically correct under the standard, even though the types do overlap in memory.
The deeper explanation is in Taking a Byte Out of C++ - Avoiding Punning by Starting Lifetimes, which covers why C++ went this direction.
\nIf you’re writing C and need to type pun, use a union or memcpy.
Pointer casts “work” until they don’t. And “don’t” means the compiler\nsilently optimises away the code you thought was executing. If you’re\nwriting C++, the same applies, plus the compiler has more latitude to\nbreak things under the as-if rule.
\nThe bug I started with? A pointer cast from float* to uint32_t* in a hot loop. At -O2, the loop was optimised under strict aliasing assumptions, and the values I was writing never appeared where I expected them. A union fixed it in ten minutes.