Type Punning in C and C++

以下正文同步自 Hacker News，版权归原站所有，已转换为易读排版。

c

undefined-behavior

c++

About 7 min read

I had a bug that took me a while to track down. The problem

was type punning. A pointer cast worked fine at -O0 and

silently broke at -O2. The C vs C++ distinction here is genuinely

treacherous, and most blog posts on the topic get it wrong.

Type punning is interpreting memory as different types between reads

and writes. It’s essential for serialisation, network protocols, and

low-level hardware access.

The problem is that “works in practice” and

“has defined behaviour” are different things.

In 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.

This is defined behavior in C:

union {

float f;

uint32_t bits;

} pun;

pun.f = 3.14f;

uint32_t exp = (pun.bits >> 23) & 0xff; // extract IEEE-754 exponent

This also works beautifully for pulling apart structs:

union {

struct color { float r, g, b, a; } c;

float as_array[4];

} u;

u.c = (struct color){ .r = 1, .a = 1 };

float a = u.as_array[3];

memcpy

If you don’t want a union, memcpy is safe and the compiler will optimise it to a register move:

float f = 3.14f;

int i;

memcpy(&i, &f, sizeof(f)); // defined behavior, compiles to a single instruction

Pointer Casts — Convenient but UB

This compiles, runs, and gives you the “right” answer on every platform:

float f = 3.14f;

int *p = (int *)&f;

int i = *p;

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.

In 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.

This has concrete consequences. Consider:

struct c {

uint32_t a;

uint32_t b;

};

uint32_t bar(uint64_t *u64, struct c *c) {

if (c->a == 2) {

*u64 = 4;

}

if (c->a == 2) {

return c->a;

}

return c->b;

}

int main() {

struct c c = { 2, 3 };

return bar((uint64_t *) &c, &c);

}

With 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.

If 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

silently optimises away the code you thought was executing. If you’re

writing C++, the same applies, plus the compiler has more latitude to

break things under the as-if rule.

The 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.

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。