[415] Undefined Behavior: O Território Perigoso do C

Ao longo de todo este curso, uma expressão apareceu repetidamente como um aviso: comportamento indefinido. Surgiu ao falar de vetores fora dos limites, ponteiros nulos, uso de memória liberada, estouro de inteiros. Chegou a hora de encará-la de frente, sistematicamente, porque compreender o comportamento indefinido é compreender a alma do C — sua velocidade extrema e seu perigo, que são as duas faces da mesma moeda. Esta aula não ensina uma técnica nova; ela consolida uma consciência de risco que fará de você um programador C mais seguro e mais sábio.

O que é, afinal, comportamento indefinido

O comportamento indefinido (undefined behavior, ou UB) é um conjunto de situações que o padrão da linguagem C deliberadamente deixa sem definição. Quando seu programa faz algo que é UB, o padrão não garante nada sobre o que acontecerá. O programa pode travar, pode produzir um resultado errado, pode parecer funcionar perfeitamente, pode corromper dados silenciosamente, ou pode se comportar de forma diferente a cada execução ou a cada compilador. Não há garantia alguma — literalmente qualquer coisa é permitida do ponto de vista do padrão.

Isso é radicalmente diferente de um erro comum. Um erro de lógica produz um resultado errado, mas previsível e reproduzível. O UB não oferece nem essa cortesia: ele é imprevisível por definição. É essa imprevisibilidade que o torna a fonte dos bugs mais frustrantes do C — aqueles que "às vezes funcionam", que somem quando você adiciona um printf, que aparecem só num compilador ou só em produção.

Por que o C tem comportamento indefinido

Pode parecer um defeito, mas o UB é uma escolha de design deliberada, e entender o porquê ilumina toda a filosofia da linguagem. O C foi projetado para ser rápido e próximo da máquina. Verificar cada acesso a vetor, cada ponteiro, cada operação aritmética teria um custo de desempenho — e o C recusou esse custo. Ao declarar essas verificações como "responsabilidade do programador" e o que acontece na sua ausência como "indefinido", a linguagem libera o compilador para gerar código máximamente eficiente, assumindo que você nunca cometerá esses erros.

É o mesmo pacto que discutimos lá na primeira aula: o C confia em você. O UB é a contrapartida dessa confiança. O compilador assume que seu programa não tem UB e otimiza agressivamente com base nessa suposição. Quando a suposição é violada, o resultado é imprevisível — não porque o compilador seja malicioso, mas porque ele construiu tudo sobre uma premissa que você quebrou. Linguagens como Rust fizeram a escolha oposta (verificar tudo, ao custo de mais rigor); o C escolheu a velocidade e a responsabilidade. Nenhuma escolha é "certa" — são filosofias diferentes.

Um catálogo dos UBs que já encontramos

Vale reunir num só lugar os comportamentos indefinidos que espalhamos pelo curso, para você reconhecê-los. Acesso fora dos limites de um vetor (aula Vetores e o Primeiro Contato com a Memória Contígua) — ler ou escrever v[10] num vetor de 5. Desreferenciar ponteiro nulo ou inválido (aula Ponteiros: O que É um Endereço de Memória) — usar *p quando p é NULL ou aponta para lixo. Use-after-free e double-free (aula Alocação Dinâmica: malloc, calloc, realloc e free) — usar ou liberar memória já liberada. Ler memória não inicializada — usar uma variável antes de atribuir-lhe valor. Estouro de inteiro com sinal — quando uma operação com int excede seu valor máximo (curiosamente, o estouro de unsigned é definido, mas o de signed é UB). Modificar uma string literal (aula Strings: Vetores de Caracteres e a Biblioteca string.h) — alterar os caracteres de um char *s = "...". E o descasamento de especificadores em printf/scanf (aula Entrada e Saída Formatada: printf e scanf a Fundo). Cada um desses foi um aviso pontual; juntos, formam o mapa do território perigoso.

Um exemplo que revela a traição do UB

Para sentir por que o UB é tão insidioso, veja como ele pode enganar completamente sua intuição:

#include <stdio.h>

int main(void) {
    int v[5] = {0};

    for (int i = 0; i <= 5; i++) { // BUG: <= vai até 5, mas v só tem índices 0-4
        v[i] = i * 10;             // v[5] é escrita fora dos limites: UB
        printf("v[%d] = %d\n", i, v[i]);
    }
    return 0;
}

Este programa tem um clássico erro de "um a mais" (<= em vez de <), escrevendo em v[5], que não existe. O que acontece? Depende. Pode rodar e imprimir tudo como se estivesse certo. Pode travar. Pode entrar num laço infinito bizarro (se v[5] calhar de sobrescrever a variável i na pilha, resetando o contador). Pode funcionar na sua máquina e falhar na do colega. Nenhum desses resultados é "o correto" — todos são manifestações válidas de UB. É exatamente essa imprevisibilidade que torna o UB tão perigoso: o programa pode parecer saudável e esconder uma bomba-relógio.

O agravante moderno: o compilador otimizador

Há uma dimensão do UB que surpreende até programadores experientes e que vale conhecer. Compiladores modernos otimizam assumindo que o UB nunca acontece. Isso significa que a presença de UB pode fazer o compilador tomar decisões que eliminam código ou mudam comportamento de formas inesperadas. Por exemplo, se o compilador vê um código que só faria sentido caso um ponteiro fosse nulo, mas o código já desreferenciou esse ponteiro antes (o que seria UB se fosse nulo), ele pode assumir que o ponteiro nunca é nulo e remover a verificação, porque, na sua lógica, um ponteiro que foi desreferenciado com sucesso não pode ser nulo. O resultado é que o UB não apenas afeta a linha onde ocorre — ele pode fazer o compilador transformar partes distantes do programa de maneiras difíceis de prever. É por isso que a máxima entre programadores C é séria: UB não é "um comportamento estranho", é a ausência total de garantias, e deve ser evitado com rigor, não gerenciado.

Como se defender do comportamento indefinido

A boa notícia é que você já conhece as defesas — elas foram construídas ao longo do curso. Compile sempre com avisos (-Wall -Wextra): o compilador detecta muitos casos potenciais de UB e os reporta. Use os sanitizers (-fsanitize=address,undefined) das aulas Caçando Bugs de Memória com Valgrind e Sanitizers: o UndefinedBehaviorSanitizer foi feito exatamente para flagrar UB em tempo de execução, transformando o imprevisível em uma mensagem clara. Adote a disciplina defensiva que praticamos: verificar limites de vetores, checar ponteiros contra NULL antes de usá-los, respeitar o par malloc/free, garantir terminadores em strings. E conheça as regras — muitos UBs (como o estouro de inteiro com sinal ou modificar literais) são evitáveis simplesmente sabendo que existem. A defesa contra o UB não é uma técnica única, mas a soma de todos os bons hábitos que o curso vem cultivando.

O que vem a seguir

Hoje consolidamos a consciência de risco que atravessa todo o C: o comportamento indefinido, essa ausência deliberada de garantias que é o preço da velocidade da linguagem. Vimos o que é, por que existe (o pacto de confiança e desempenho), o catálogo dos casos comuns, sua traição imprevisível e o agravante das otimizações — e, sobretudo, como as ferramentas e hábitos do curso nos defendem dele. Na próxima aula, aplicamos essa mentalidade de robustez a um aspecto específico e prático: o tratamento de erros idiomático em C — como funções sinalizam falhas através de valores de retorno e da variável errno, e como escrever código que lida com o que dá errado de forma limpa e confiável.

Fontes e leituras recomendadas

• The C Programming Language (K&R), Kernighan & Ritchie — as bases da semântica da linguagem
• "What Every C Programmer Should Know About Undefined Behavior" — série clássica do blog do LLVM — https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
• cppreference — Undefined behavior — https://en.cppreference.com/w/c/language/behavior
• UndefinedBehaviorSanitizer — a ferramenta de detecção — https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
• CERT C — catálogo abrangente de regras que previnem UB — https://wiki.sei.cmu.edu/confluence/display/c

Exercícios

Exercício 1

Liste cinco exemplos distintos de comportamento indefinido que apareceram ao longo do curso, e para cada um explique brevemente qual regra é violada.

Exercício 2

Compile e rode o programa do laço com <= 5 (acesso a v[5]) do artigo, primeiro normalmente, depois com -fsanitize=address,undefined. Descreva a diferença: o que o programa faz sem os sanitizers e o que os sanitizers reportam?

Exercício 3

Explique por que o estouro de um inteiro com sinal (signed) é comportamento indefinido, enquanto o estouro de um inteiro sem sinal (unsigned) é bem definido pelo padrão. (Pesquise se necessário; o ponto é entender que unsigned "dá a volta" de forma garantida.)

Exercício 4

Explique, com suas palavras, por que o comportamento indefinido é uma consequência da filosofia de design do C. Como ele se relaciona com o "pacto de confiança" mencionado desde a primeira aula?

Exercício 5

Descreva quatro defesas práticas contra o comportamento indefinido que você aprendeu ao longo do curso. Para cada uma, explique como ela ajuda a prevenir ou detectar UB.