Type punning em C e C++ falha silenciosamente no -O2

Um post publicado em 21 de setembro de 2026 no blog Personal Workflow Blog (leia aqui) reacendeu uma discussão que qualquer pessoa que já mexeu com serialização binária, protocolos de rede ou acesso direto a hardware em C conhece de cor: type punning, a prática de interpretar a mesma região de memória como tipos diferentes na escrita e na leitura. O autor descreve um bug que levou um tempo para ser rastreado: um pointer cast de float para uint32_t funcionava perfeitamente em -O0 e quebrava silenciosamente em -O2. A causa não foi um erro de lógica, foi undefined behavior que só se manifesta quando o otimizador decide confiar no que a linguagem promete.

O que é type punning e por que ele existe

Type punning é indispensável em código de baixo nível: extrair o expoente IEEE-754 de um float, montar um pacote de rede byte a byte, ou reinterpretar um struct como array. O problema, como o post resume bem, é que "funciona na prática" e "tem comportamento definido" são coisas diferentes. Compiladores modernos não são obrigados a preservar o comportamento que você observou empiricamente, só o que o padrão da linguagem garante.

As duas formas seguras em C: union e memcpy

Em C, duas técnicas são comportamento definido. A primeira é a union:

union {
 float f;
 uint32_t bits;
} pun;

pun.f = 3.14f;
uint32_t exp = (pun.bits >> 23) & 0xff; // extrai o expoente IEEE-754

O mesmo padrão funciona para desmontar structs inteiros, como um struct color { float r, g, b, a; } lido como array de floats através de uma union.

A segunda é memcpy, que parece cara mas o compilador otimiza para um simples move de registrador:

float f = 3.14f;
int i;
memcpy(&i, &f, sizeof(f)); // comportamento definido, vira uma instrução só

Ambas custam zero em runtime depois de compiladas. A diferença para o pointer cast não é performance, é garantia.

O pointer cast que funciona até parar de funcionar

O padrão mais comum, e o mais perigoso, é o cast direto:

int *p = (int *) &f;
int i = *p;

Isso compila, roda e dá a resposta "certa" em qualquer plataforma que você testar. E ainda assim é undefined behavior, porque viola a strict aliasing rule: um objeto só pode ser acessado através de um lvalue do seu tipo efetivo, uma versão qualificada dele, ou um tipo char. Um ponteiro convertido para um tipo não relacionado quebra essa regra, e o compilador está livre para assumir que isso nunca acontece.

O bug real: por que -O1 e -O2 dão respostas diferentes

O exemplo do post mostra o efeito prático dessa liberdade. Dado o código:

struct c {
 uint32_t a;
 uint32_t b;
};

uint32_t bar(uint64_t *u64, struct c *c) {
 if (c->a == 2) {
 *u64 = 4;
 }
 return c->a;
}

int main() {
 struct c c = { 2, 3 };
 return bar((uint64_t *) &c, &c);
}

Com GCC ou Clang em -O2, essa função retorna 2. Em -O1 ou abaixo, retorna 0. A diferença: o compilador enxerga u64 como uint64_t e c como struct c, tipos diferentes, e assume que eles não fazem aliasing entre si. A segunda checagem c->a == 2 é eliminada porque, sob essa suposição, escrever em *u64 jamais poderia alterar c->a. Do ponto de vista do padrão, o compilador está certo, mesmo que os dois ponteiros apontem para o mesmo endereço de memória na prática.

É esse tipo de comportamento que torna o strict aliasing um dos motivos mais comuns de bug que "só aparece com otimização ligada" em C e C++↳C++6 conteúdosSão Paulo recebe encontro de Programadores C & C++Dev (Back & Front) · mai 2019Melhores linguagens de programação para desenvolver jogosMarketing Tech · nov 2024Desmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Ver tudo em Dev (Back & Front) →, e que costuma ser descartado erroneamente como bug do compilador quando na verdade é código com UB que deixou de ter sorte.

Por que C e C++ divergem aqui

O post aponta uma diferença de filosofia que explica por que a mesma técnica é mais arriscada em C++: em C, tipos são uma forma de interpretar memória; em C++, tipos são cidadãos de primeira classe, e o compilador tem permissão explícita para assumir que tipos diferentes nunca fazem aliasing entre si. Isso dá ao compilador C++ ainda mais margem para otimizações agressivas sob a "as-if rule", a regra que permite qualquer transformação desde que o comportamento observável não mude, no bom entendimento do compilador. O post cita o artigo "Taking a Byte Out of C++, Avoiding Punning by Starting Lifetimes" como referência mais aprofundada sobre essa escolha de design da linguagem.

O que muda para quem mantém código legado

Código C e C++ escrito nos anos 2000 e 2010 está cheio de pointer casts para type punning, muitas vezes porque a union parecia "verbosa demais" ou porque o time nunca leu a strict aliasing rule até o fim. Esse código roda hoje em -O0 ou -O1 sem problema aparente. O risco concreto: qualquer atualização de toolchain, mudança de flags de build, ou subida de -O1 para -O2/-O3 numa etapa de release pode expor comportamento diferente sem nenhuma mudança de código-fonte. Isso é particularmente traiçoeiro em pipelines onde debug builds usam -O0 e produção usa -O2 ou superior: o bug simplesmente não existe em debug.

A regra prática do post é direta: em C, use union ou memcpy para type punning, nunca pointer cast. Em C++, a recomendação vale igual, com um agravante: o compilador tem ainda mais liberdade para quebrar esse tipo de código sob a as-if rule.

O autor do post fechou o próprio caso assim: um pointer cast de float para uint32_t num loop quente, otimizado sob as premissas de strict aliasing em -O2, fazendo os valores escritos nunca aparecerem onde eram esperados. A correção com union levou dez minutos. Encontrar o bug levou bem mais.

Fonte: Hacker News