Depuração, comportamento indefinido e C seguro

Os avisos dão a você a chance de corrigir um defeito antes que uma entrada o desencadeie. Um erro impede que a compilação seja concluída. Um aviso permite que a compilação continue, mas informa algo que você precisa entender: código válido suspeito, possível comportamento indefinido ou uma violação das regras da linguagem que o compilador aceita.

Escolha verificações úteis

Inicie GCC ou Clang com uma versão explícita da linguagem e um conjunto amplo de avisos:

clang -std=c17 -Wall -Wextra -Wpedantic -g program.c -o program

-Wall ativa muitas verificações comuns, não todos os avisos. -Wextra adiciona outras, incluindo comparações entre valores com e sem sinal em C. -Wpedantic diagnostica muitas divergências em relação ao padrão ISO escolhido; não é um teste completo de conformidade. /W4 do MSVC cumpre uma função semelhante no Windows.

Adicione verificações adequadas aos riscos do seu código:

Por exemplo, double price = 3.7; int whole = price; descarta a parte fracionária. -Wconversion torna essa conversão visível. Se o truncamento for intencional e o valor couber no tipo, (int)price explicita a escolha. Se a parte fracionária importar, mantenha um tipo de ponto flutuante. Para arredondar ao inteiro mais próximo, lround de <math.h> tem uma função diferente de uma conversão explícita.

Leia a primeira mensagem útil

Um diagnóstico normalmente identifica um local no código-fonte, uma mensagem e a opção de aviso. Um acento circunflexo marca a expressão relevante; notas seguintes podem identificar uma declaração ou sugerir uma correção. Leia o grupo inteiro. Quando um erro de sintaxe causar muitas mensagens posteriores, corrija o primeiro erro e compile novamente antes de investigar as demais.

Suponha que um programa contenha estas três linhas, com average declarado como double:

if (count = 0) { /* report no data */ }
printf("%d\n", average);
int unused;

A atribuição na condição define count como zero, tornando a condição falsa. Se a intenção era fazer uma comparação, use count == 0. Adicionar parênteses ao redor da atribuição pode silenciar um aviso e manter o defeito intacto.

O formato %d espera um int, mas o argumento é um double. Use %f; uma incompatibilidade de formato é comportamento indefinido, não uma solicitação para converter o valor. Exclua a declaração não usada se ela não tiver nenhuma finalidade. São três causas diferentes, então cada uma precisa de sua própria correção.

Siga as evidências

Preste atenção especial a valores não inicializados, retornos ausentes, endereços de variáveis locais retornados e sizeof em parâmetros de arranjo. A falta de um cabeçalho pode deixar uma função não declarada; versões recentes de GCC e Clang rejeitam isso por padrão. Não adicione uma conversão explícita apenas para fazer um diagnóstico desaparecer. Primeiro explique os tipos e valores pretendidos, depois faça o código expressar essa intenção.

Um programa sem avisos ainda pode ter uma condição de laço incorreta ou um índice inválido fornecido pela entrada. Alguns avisos também dependem de otimização e análise de fluxo de dados, e compiladores diferentes detectam casos diferentes. Mantenha o conjunto de avisos ativado nas compilações comuns e depois investigue o comportamento em tempo de execução com o depurador e ferramentas de teste.

O mesmo código-fonte pode ser compilado para facilitar a inspeção, para testes intensivos ou para uma distribuição eficiente. As configurações de compilação determinam quais informações você pode ver e quais verificações adicionais são executadas. Dê uma finalidade clara a cada versão compilada.

Mantenha informações do código-fonte

A opção -g adiciona nomes, tipos e mapeamentos entre instruções de máquina e linhas do código-fonte. Ela permite que um depurador mostre seu código e ajuda relatórios de sanitizadores a identificar locais. Ela não ativa verificações em tempo de execução nem desativa a otimização. Sem informações de depuração, alguns nomes de funções ainda podem estar disponíveis, mas é muito mais difícil recuperar linhas do código-fonte e variáveis locais.

A otimização altera o quanto a execução segue a ordem do código-fonte:

Uma sessão de depuração otimizada pode pular linhas ou exibir uma variável como “”. O compilador preservou o comportamento do código definido, mas pode não manter mais todos os valores intermediários do código-fonte. -O0 não traduz literalmente cada linha de C em uma instrução de máquina.

Compile para a finalidade

Um comando simples de depuração é:

gcc -std=c17 -Wall -Wextra -Wpedantic -g -O0 program.c -o program-debug

Uma versão de teste adiciona sanitizadores. Uma versão para distribuição costuma usar -O2 e pode definir NDEBUG para remover asserções. A validação comum de entrada e o tratamento de erros devem permanecer ativos quando as asserções desaparecerem. Teste também a configuração de distribuição: um problema visível apenas com otimização é um forte motivo para investigar comportamento indefinido, incluindo leituras de valores não inicializados e estouro de inteiro com sinal.

Mantenha opções compartilhadas em um Makefile ou em outra configuração de compilação. Nomes de saída separados evitam que você execute acidentalmente um binário antigo de distribuição enquanto inspeciona código-fonte recém-editado. Após cada alteração no código-fonte, recompile o executável que pretende executar.

Adicione análise e reforço de segurança

A análise estática acompanha possíveis caminhos pelo código-fonte sem executar o programa. Experimente gcc -fanalyzer ou clang --analyze; scan-build, clang-tidy e cppcheck oferecem outros fluxos de análise. Um analisador pode perceber que um ramo de erro libera um ponteiro duas vezes mesmo quando seus testes nunca entram nesse ramo. Examine seu raciocínio: a análise de caminhos possíveis pode produzir alarmes falsos.

A análise dinâmica verifica a execução real. Sanitizadores e Valgrind veem apenas os caminhos que você executa, portanto sua cobertura depende das entradas. Combine os dois tipos de análise.

O reforço de segurança para distribuição limita os danos de defeitos restantes. -fstack-protector-strong insere verificações em registros de ativação selecionados para detectar muitas sobrescritas. Em sistemas compatíveis, _FORTIFY_SOURCE adiciona verificações a chamadas de biblioteca quando os tamanhos dos objetos podem ser determinados. Ela exige otimização; o nível 2 é comum, enquanto o nível 3 exige suporte adequado do compilador e da biblioteca C. Esses são recursos da plataforma, não garantias do ISO C.

Um programa com reforço de segurança pode parar quando detecta corrupção. A operação inválida ainda precisa ser corrigida no código-fonte; alterar opções de distribuição não pode corrigir um laço que ultrapassa os limites.

Uma falha é o comportamento que você vê: um encerramento inesperado, um total incorreto ou uma saída que nunca aparece. Um defeito é o erro que a causou. Manter os dois conceitos separados evita que você altere a linha do encerramento antes de descobrir como o programa chegou até ela.

Torne a falha reproduzível

Registre o comando, a entrada, as opções de compilação, o resultado esperado e o resultado real. Mantenha a entrada que causa a falha inalterada enquanto experimenta. Se um programa falhar apenas com um arquivo, salve esse arquivo antes de editá-lo. A reprodução oferece uma forma de avaliar se uma correção proposta funciona.

Em seguida, reduza o caso preservando a falha. Remova registros ou código sem relação com ela e execute novamente. Suponha que um registro entre 1.000 desencadeie um encerramento inesperado por si só. Testar metades pode localizá-lo em cerca de 10 rodadas. Se nenhuma das metades falhar sozinha, a falha pode exigir uma sequência de registros ou um estado acumulado antes. Preserve essa sequência e remova partes menores ao redor dela. Dividir ao meio só é útil quando a entrada mantida ainda exercita a causa.

Faça uma pergunta testável por vez

Um campo vazio em um arquivo reduzido sugere uma hipótese: “O analisador usa o campo antes de verificar se ele existe”. Teste-a com uma entrada pequena que contenha um campo vazio. Inspecione o ponteiro retornado ou adicione uma verificação específica. Altere uma coisa por vez; se você alterar o analisador, o tamanho do buffer e a entrada ao mesmo tempo, o sucesso não revelará qual alteração teve efeito.

Corrija a regra violada, execute novamente o caso reduzido e depois execute novamente a entrada original e os testes existentes. Guarde a entrada que desencadeia a falha como um teste de regressão para que uma edição posterior não possa restaurar a mesma falha silenciosamente.

Interprete a parada

“Segmentation fault” geralmente informa SIGSEGV: o sistema interrompeu um acesso inválido à memória. Um ponteiro nulo, um ponteiro liberado ou um endereço fora dos limites é uma causa comum. Um acesso inválido também pode não causar um encerramento imediato, portanto a ausência de mensagem, por si só, revela pouco.

“Aborted” geralmente informa SIGABRT, gerado por abort(). Uma asserção que falhou ou uma verificação da biblioteca que detectou corrupção do heap pode causá-lo. No bash, códigos de saída comuns para sinais são 139 para SIGSEGV e 134 para SIGABRT; esses números são convenções do shell, não valores de retorno de C que seu programa precise usar.

Observe sem perder a saída

Um diagnóstico curto pode revelar o primeiro valor incorreto:

fprintf(stderr, "index=%zu total=%d\n", index, total);

Rótulos tornam a saída legível quando a mesma linha é executada muitas vezes. stderr é útil para diagnósticos porque não usa armazenamento completo em buffer; stdout redirecionado para um arquivo ou canal entre processos normalmente usa armazenamento completo em buffer, então um encerramento inesperado pode fazer a saída pendente se perder. Remova as impressões temporárias após a correção.

Explique uma função suspeita linha por linha em voz alta. Esse método do “pato de borracha” obriga você a relacionar cada operação ao comportamento pretendido. Se um defeito mudar quando você adicionar impressões ou alterar a otimização, investigue comportamento indefinido com sanitizadores. Aumentar um arranjo até um encerramento inesperado desaparecer pode ocultar um índice inválido sem corrigi-lo.

Um depurador permite pausar um programa em execução e inspecionar os valores que explicam seu comportamento. Use GDB em muitos sistemas Linux ou LLDB no macOS. Os botões de depuração das IDEs usam as mesmas ideias: parar, executar, inspecionar e avançar passo a passo.

Comece pelo executável correto

Compile com -g -O0 e depois abra o resultado com gdb ./program ou lldb ./program. No prompt, run records.txt 3 inicia o programa com dois argumentos. No GDB, run < input.txt redireciona a entrada padrão; no LLDB, use process launch -i input.txt. Use quit para sair.

Defina um ponto de parada antes de executar. break main no GDB e b main no LLDB param no início de main. Ambos aceitam uma localização por arquivo e linha, como b program.c:12. Os comandos completos do LLDB incluem breakpoint set --name main e breakpoint set --file program.c --line 12.

Um ponto de parada normalmente interrompe a execução antes que a instrução indicada no código-fonte seja executada. Se a linha selecionada atribuir um valor, imprima-o depois de avançar sobre ela para inspecionar o novo valor. Recompile após editar o código-fonte: o depurador executa código de máquina, não o texto aberto no editor.

Escolha como avançar

Outros pontos de parada podem interromper next ou finish. Use next para uma chamada de biblioteca que você não precisa inspecionar. Se entrar em código que não deseja examinar, finish retorna o controle à função chamadora.

Inspecione um laço uma passagem por vez

Considere um total inicializado com zero e este arranjo:

int a[5] = {4, 8, 15, 16, 23};
for (int i = 0; i <= 5; ++i) {
    sum += a[i];
}

Pare no corpo do laço e imprima i e sum antes da adição. Após as primeiras cinco adições, os totais acumulados são 4, 12, 27, 43 e 66. Na próxima parada, i == 5, mas os índices válidos terminam em 4. Você encontrou a iteração extra sem precisar ler o elemento inválido. Altere a condição para i < 5, recompile e execute novamente.

print expr ou p expr avalia uma expressão em qualquer um dos depuradores. Comece com observações seguras, como p i e p sum; uma expressão do depurador que desreferencia um ponteiro inválido pode tentar uma leitura inválida. display i do GDB repete a impressão a cada parada. info locals no GDB e frame variable no LLDB mostram as variáveis locais. Para cinco elementos válidos acessados por ptr, use p *ptr@5 no GDB ou parray 5 ptr no LLDB.

Você pode testar uma hipótese alterando um valor enquanto o programa está pausado: o GDB aceita set var i = 4, enquanto o LLDB aceita expr i = 4. Isso altera uma execução, não o código-fonte. Para gerenciar as paradas, use info breakpoints e delete 1 no GDB, ou breakpoint list e breakpoint delete 1 no LLDB.

Um encerramento inesperado dentro de uma biblioteca muitas vezes começa com um argumento inválido vindo do seu código. A pilha de chamadas mostra as chamadas de função ativas. Use-a para sair do local da parada e chegar à função chamadora cujos valores você pode explicar.

Leia os registros de ativação a partir da chamada atual

Digite bt em qualquer um dos depuradores. O registro #0 é a chamada ativa mais interna; os registros com números maiores são suas funções chamadoras. Um registro fornece o contexto de execução da função, incluindo os argumentos e as variáveis locais disponíveis. A otimização pode remover parte dessas informações.

Suponha que find_name(2) não encontre uma correspondência e que a função chamadora faça isto:

const char *name = find_name(2);
printf("%zu\n", strlen(name));

A parada pode ocorrer dentro de strlen. Em bt, encontre o primeiro registro que pertence ao seu código. Se ele for o registro 1, selecione-o com frame 1 no GDB ou frame select 1 no LLDB. Imprima name. Um valor nulo explica por que a operação com a cadeia de caracteres falhou. A função chamadora deve tratar a ausência do nome antes de chamar strlen; editar a biblioteca não pode corrigir o argumento.

Use up e down para se mover entre as funções chamadoras e as chamadas. Selecionar um registro altera o que o depurador exibe e a quais variáveis locais uma expressão se refere. Isso não retoma a execução nem desfaz uma chamada.

Pare onde um valor muda

Um ponto de parada pergunta: “O que acontece neste local?”. Um ponto de observação pergunta: “Qual operação altera este valor?”. Se uma contagem armazenada se tornar incorreta muito antes de um encerramento inesperado, pause enquanto a contagem estiver no escopo e use:

GDB:  watch count
LLDB: watchpoint set variable count

Continue até o depurador parar em uma alteração. Inspecione os valores antigo e novo e o local no código-fonte da instrução que escreveu o valor. Uma alteração pode ser legítima, portanto compare-a com a regra da estrutura de dados. O hardware oferece apenas um pequeno número de pontos de observação; quatro é comum em x86-64. O armazenamento de uma variável local só tem significado enquanto sua função está ativa.

Para uma iteração tardia conhecida, use um ponto de parada condicional. break 20 if i == 999 do GDB pausa na linha 20 somente quando a condição é verdadeira. O equivalente no LLDB é breakpoint set --line 20 --condition 'i == 999'. Isso economiza centenas de passos manuais.

Inspecione um encerramento salvo

Um despejo de memória do processo registra o estado de um processo encerrado inesperadamente. Onde despejos estão ativados, ulimit -c unlimited os permite para programas iniciados nesse shell. Abra um despejo salvo com gdb ./program core ou lldb ./program -c core, usando o executável que o produziu. As políticas do sistema controlam se um despejo é salvo e onde ele fica; sistemas Linux baseados em systemd podem gerenciá-lo por meio de coredumpctl.

Execute bt, selecione seu registro de ativação e inspecione os valores como faria em um encerramento observado ao vivo. O despejo não permite continuar o programa. Se malloc ou free detectar corrupção, a escrita inválida original pode não estar nessa pilha. Reproduza o problema com AddressSanitizer para parar mais perto dessa escrita. Se um valor local parecer arbitrário, verifique se a execução chegou à sua inicialização antes de culpar o depurador.

Comportamento indefinido, ou UB, significa que o padrão C não impõe requisitos sobre o que acontece após uma operação inválida. Ele não promete uma exceção, uma mensagem de erro útil ou um valor previsível após retornar ao início da faixa. Um programa pode ser encerrado inesperadamente, corromper dados, imprimir uma resposta plausível ou parecer funcionar.

Diferencie três tipos de comportamento

O comportamento definido pela implementação pode ser usado deliberadamente quando a plataforma documentada faz parte do projeto de um programa. Para código portável, evite presumir que todas as implementações fazem a mesma escolha. O comportamento não especificado também é válido: f(a(), b()) pode avaliar qualquer uma das chamadas independentes primeiro. Escreva código cuja correção resista a essa variação permitida. A largura de int e, em C17, o deslocamento para a direita de um inteiro negativo com sinal são outras escolhas que dependem da plataforma.

Por que a otimização revela defeitos

C deixa as verificações de limites de arranjos e de soma com sinal para o programador. O compilador pode otimizar supondo que o programa obedece às regras da linguagem. Uma tentativa de detectar estouro pode violar justamente a regra que procura testar:

int will_overflow(int x) {
    return x + 1 < x;
}

Para todo x em que a soma com sinal é definida, x + 1 é maior que x. Portanto, o compilador pode substituir o resultado por zero. Em INT_MAX, fazer a soma é UB, então o compilador não deve à função chamadora um resultado que retorne ao início da faixa. Ver uma resposta diferente em uma versão compilada sem otimização não torna esse teste válido.

O teste seguro é executado antes da operação:

if (x == INT_MAX) {
    /* handle overflow */
} else {
    ++x;
}

Use <limits.h> para obter os limites da implementação. Um máximo fixado no código pressupõe uma determinada largura de tipo; a macro identifica o limite real.

Coloque as verificações antes do primeiro uso

Essa ordem também é essencial para ponteiros:

if (p == NULL) {
    return -1;
}
int v = *p;

Inverter essas instruções permite que uma desreferenciação nula ocorra antes da proteção. Depois que o código desreferencia p, um otimizador pode concluir que o caminho definido já exige que p não seja nulo e remover uma verificação de nulidade posterior.

Alterar opções de compilação, adicionar uma impressão ou mover uma variável pode mudar o sintoma visível de UB. Uma execução bem-sucedida estabelece apenas o que aquela versão compilada fez para aquela entrada. Para corrigir o código, identifique qual operação não tem significado definido e qual condição deve ser verdadeira antes dela. Avisos podem identificar alguns casos; a análise estática pode explorar caminhos possíveis; ASan e UBSan verificam muitas operações executadas. Regras de codificação fornecem os padrões correspondentes no código-fonte, como verificar um índice ou um limite aritmético antes de usá-lo.

Uma operação aritmética pode falhar antes que você tenha a chance de inspecionar seu resultado. Verifique os operandos enquanto seus valores ainda são válidos e saiba qual tipo executa cada operação.

Limites de tipos com e sem sinal

O estouro de inteiro com sinal é indefinido. Com um int de 32 bits, INT_MAX é 2.147.483.647; somar um não é uma forma portável de obter um número negativo. INT_MIN / -1, -INT_MIN e uma multiplicação excessiva também falham quando o resultado matemático não cabe no tipo.

A aritmética sem sinal sofre redução modular dentro da faixa de seu tipo. Para um unsigned int de 32 bits, UINT_MAX + 1u é zero, e 0u - 1u é 4.294.967.295. Isso é definido, mas ainda pode prejudicar um cálculo de tamanho. Um laço decrescente sem sinal que usa i >= 0 nunca alcança um valor negativo de parada.

Para uma soma geral com sinal, teste antes de somar:

if ((b > 0 && a > INT_MAX - b) ||
    (b < 0 && a < INT_MIN - b)) {
    /* report overflow */
} else {
    result = a + b;
}

As subtrações usadas nesses testes permanecem na faixa porque cada uma é protegida pela verificação do sinal de b. Calcular primeiro a soma e depois compará-la é tarde demais. Um tipo de maior faixa só ajuda quando consegue armazenar todos os resultados intermediários: converta um operando antes da operação. C23 fornece ckd_add em <stdckdint.h>; GCC e Clang oferecem __builtin_add_overflow.

Divisão, deslocamentos de bits e conversões

Rejeite zero antes de uma divisão inteira ou operação de resto. Rejeite também a divisão do mínimo de um tipo com sinal por menos um quando o resultado não puder ser representado. Sistemas de ponto flutuante IEEE 754 costumam produzir infinito ou NaN para divisão por zero, permitindo que resultados numéricos inválidos se propaguem sem uma interrupção como a de operações inteiras.

Para operações com bits, use operandos sem sinal. A quantidade de deslocamento deve ser não negativa e menor que a largura do operando esquerdo após a promoção. Com operandos de 32 bits, deslocar por 32 é indefinido. Em C17, deslocar um valor negativo com sinal para a esquerda é indefinido; 1 << 31 também é indefinido para um int de 32 bits, enquanto 1u << 31 é válido para um unsigned int de 32 bits.

Uma conversão de ponto flutuante para inteiro exige que o valor truncado caiba no tipo, mesmo quando o destino é sem sinal. (unsigned)-1.0 é indefinido. A conversão de inteiro para um tipo sem sinal, por sua vez, reduz o valor à faixa do destino: (unsigned)-1 se torna UINT_MAX. A conversão de um inteiro fora da faixa para um tipo com sinal é definida pela implementação em C17. Verifique as faixas antes de converter para um tipo de menor faixa; -Wconversion ajuda a revelar alterações implícitas.

Torne a ordem de avaliação inofensiva

printf("%d %d\n", i, ++i); lê e altera i sem a ordenação necessária. i = i++ + 1; e a[i] = i++; também contêm operações não sequenciadas. Divida o trabalho em instruções separadas com uma ordem pretendida explícita.

Inicialize variáveis automáticas antes de lê-las: int sum = 0; torna sum += x; significativo. Variáveis globais e estáticas começam em zero. A exigência de representação em complemento de dois do C23 não define o estouro de inteiro com sinal; código portável ainda precisa das verificações.

Um ponteiro precisa de mais do que um endereço plausível. O objeto deve existir, o acesso deve permanecer dentro de seus limites e a operação deve ser permitida para esse objeto. Essas verificações explicam tanto encerramentos inesperados imediatos quanto corrupção descoberta muito depois.

Permaneça dentro do objeto

Um arranjo de n elementos tem índices de zero a n - 1. Um ponteiro para a posição imediatamente após o último elemento pode marcar o fim de um laço, mas você não deve desreferenciá-lo. i <= n visita um elemento a mais. A regra CERT ARR30-C trata desses erros de limites.

Uma escrita fora dos limites pode atingir memória acessível que pertence a outro objeto. O programa pode continuar até que uma contagem, um ponteiro ou um registro do alocador danificado seja usado. Um encerramento posterior em free não identifica a escrita original. O ASan pode parar na escrita quando suas verificações detectam a violação de limites.

Forme uma cadeia de caracteres válida

Uma cadeia de caracteres em C termina com '\0'. Seu armazenamento precisa de um byte além da contagem de caracteres. C aceita char s[5] = "hello";, mas todos os cinco bytes contêm letras, sem deixar espaço para o terminador. Passá-la para strlen ou %s pode causar uma leitura além do arranjo. Use espaço suficiente e garanta que um terminador esteja realmente presente. STR31-C trata da capacidade; STR32-C trata da passagem de uma cadeia terminada em nulo.

Um literal de cadeia de caracteres não pode ser modificado. Após char *p = "hi";, p[0] = 'H'; é indefinido. Use char p[] = "hi"; para obter uma cópia modificável, ou const char *p para tornar visíveis ao compilador as tentativas de alterar o literal. Esse é o tema de STR30-C.

Respeite o tempo de vida e a responsabilidade pela liberação

Verifique se há NULL antes de desreferenciar um resultado de alocação, abertura de arquivo ou busca. Quando um bloco é liberado, todos os ponteiros para seu interior perdem o acesso a um objeto ativo. Não leia nem escreva por meio deles e não libere o bloco novamente. Libere apenas o ponteiro apropriado retornado por uma alocação dinâmica, nunca um arranjo local ou um ponteiro para o interior de um objeto. free(NULL) é inofensivo, mas definir um ponteiro como nulo após a liberação não corrige outras referências ao mesmo objeto.

Uma função que retorna o endereço de um arranjo local retorna um ponteiro pendente:

char *greeting(void) {
    char text[16] = "Welcome";
    return text;
}

O tempo de vida do arranjo termina quando a função retorna. Forneça à função chamada um buffer e sua capacidade para que ela o preencha, ou aloque um resultado cuja responsabilidade pela liberação passe à função chamadora. Uma impressão bem-sucedida imediatamente após o retorno não pode prolongar o tempo de vida do arranjo antigo.

Aloque bytes para cada elemento

malloc(n) solicita bytes, não n objetos do tipo apontado. A expressão usual baseada no elemento é n * sizeof *a. Primeiro impeça que esse produto sofra redução modular:

if (n > SIZE_MAX / sizeof *a) {
    /* reject the requested size */
}

Inclua <stdint.h> para SIZE_MAX e <stdlib.h> para funções de alocação. Quando o tamanho for válido, aloque, verifique o ponteiro retornado e escreva cada valor antes de lê-lo. malloc deixa a memória não inicializada. calloc(n, sizeof *a) preenche seu armazenamento com zeros, e as principais bibliotecas rejeitam produtos que causam estouro. Uma verificação de tamanho, uma verificação do resultado da alocação e um índice válido resolvem problemas diferentes; os três são importantes.

Uma asserção expressa algo que deve ser verdadeiro porque seu código está correto. Ela transforma uma suposição violada e oculta em uma parada perto do ponto em que essa suposição importa.

Verifique um contrato de programação

Inclua <assert.h> e escreva assert(condition);. Uma condição verdadeira permite que a execução continue. Uma condição falsa imprime informações de diagnóstico em stderr e chama abort(). A mensagem identifica a expressão, o local no código-fonte e a função; seu texto exato depende da plataforma.

Para uma função auxiliar interna de média cuja função chamadora promete fornecer argumentos válidos:

double average(const int *a, size_t n) {
    assert(a != NULL);
    assert(n > 0);
    /* compute the average */
}

Uma chamada acidental com zero elementos falha no ponto da promessa violada. Em um depurador, bt mostra os mecanismos da asserção e de abortamento, seguidos das chamadas no seu código. Selecione o registro de ativação da função chamadora para inspecionar como ela forneceu zero.

Contratos aparecem em vários pontos:

Uma asserção é documentação executável: ela identifica a propriedade e também a verifica durante uma execução de teste. Escolha expressões que observem o estado sem alterá-lo.

Mantenha operações necessárias fora das asserções

Definir NDEBUG antes de incluir <assert.h>, normalmente com -DNDEBUG, desativa assert. Sua expressão não é avaliada. Isso cria um defeito grave se a expressão executar uma operação necessária:

assert(++count <= MAX);

O incremento desaparece em uma versão compilada com NDEBUG. Escreva a ação separadamente:

++count;
assert(count <= MAX);

A mesma regra exclui a abertura de arquivos, a alocação de memória ou o fechamento de arquivos dentro de uma asserção. Essas operações devem ocorrer em todas as configurações. Suas falhas precisam de tratamento de erros comum.

Valide falhas esperadas normalmente

Um arquivo de entrada ausente, texto inválido do usuário e memória esgotada podem ocorrer durante o uso correto do programa. Verifique esses casos com if, informe o erro e retorne ou libere os recursos. Uma função auxiliar privada pode usar uma asserção para verificar uma faixa validada, mas o ponto público de entrada deve impor essa faixa com verificações que permaneçam nas versões para distribuição.

Por exemplo, sempre teste fclose(f) == EOF no fluxo de controle comum ao fechar um arquivo de saída. A saída armazenada em buffer pode falhar durante o fechamento; remover a chamada ou sua verificação pode ocultar a perda de dados.

Verifique fatos fixos em tempo de compilação

Uma asserção estática testa uma expressão constante durante a compilação. Em C17, <assert.h> fornece static_assert como macro para _Static_assert do C11:

static_assert(sizeof(int) == 4, "requires a 4-byte int");

Uma condição falsa faz a compilação falhar. Ela não pode verificar uma contagem informada pelo usuário que só é conhecida em tempo de execução. C23 torna static_assert uma palavra-chave e permite omitir a mensagem. Use essa distinção para colocar cada verificação onde as informações necessárias estiverem disponíveis.

O AddressSanitizer, geralmente chamado de ASan, adiciona verificações às operações de memória compiladas. Ele pode relatar um acesso inválido no momento em que acontece, antes que dados corrompidos causem um encerramento inesperado em outro ponto.

Compile com as verificações ligadas ao programa

Use GCC ou Clang para compilar e ligar com ASan:

clang -std=c17 -g -fsanitize=address -fno-omit-frame-pointer program.c -o program-asan

-g fornece localizações no código-fonte. Manter ponteiros de registro de ativação ajuda nos rastreamentos da pilha de chamadas. Para um projeto com vários arquivos, instrumente os arquivos-fonte relevantes e use a opção do sanitizador também na etapa final de ligação. O MSVC fornece /fsanitize=address em versões compiladas compatíveis do Windows.

O ASan detecta muitos acessos fora dos limites de blocos do heap e de arranjos na pilha e globais. Ele também detecta uso após a liberação, liberação dupla, liberação inválida e os erros de uso após o fim do escopo para os quais há suporte. No Linux, o ambiente de execução usual do ASan inclui verificação de vazamentos no encerramento. O Clang fornecido pela Apple no macOS não oferece essa detecção de vazamentos; conjuntos de ferramentas LLVM e suporte de plataformas variam.

Siga um relatório até a causa

Considere um arranjo alocado com sucesso, com int de 4 bytes:

int *a = malloc(10 * sizeof *a);
for (int i = 0; i <= 10; ++i) {
    a[i] = i;
}

A alocação contém 40 bytes. Os índices de zero a nove usam esses bytes. O índice dez começa imediatamente após eles. O ASan pode informar “heap-buffer-overflow”, “WRITE of size 4” e uma localização a zero bytes de uma região de 40 bytes. O rastreamento da escrita identifica a atribuição; o rastreamento da alocação identifica o malloc que estabeleceu os limites do bloco.

Leia os relatórios nesta ordem:

1. Identifique a categoria do erro e se o acesso foi uma leitura ou escrita.
2. Encontre o primeiro registro de ativação no seu código no rastreamento do acesso.
3. Compare o acesso com a região alocada e seu tamanho de elemento.
4. Para um erro de tempo de vida, encontre também os rastreamentos da alocação e da liberação.

Aqui a correção é i < 10. Alocar outro elemento mantendo a regra de parada incorreta oculta a diferença entre a quantidade pretendida e o laço. O ASan para no primeiro erro detectado por padrão. Corrija-o, recompile e execute novamente.

Entenda os limites da ferramenta

O ASan acompanha a memória permitida usando memória sombra. Zonas de proteção proibidas cercam as alocações e os arranjos para os quais há suporte. Blocos liberados passam um tempo em quarentena antes da reutilização, ajudando a revelar acessos a memória que deixou de ser válida. Uma escrita além de um membro de arranjo para outro membro da mesma estrutura pode permanecer dentro de uma região válida maior e escapar à detecção.

O ASan não verifica leituras comuns de valores não inicializados. O Memcheck do Valgrind pode encontrar esses usos e muitos defeitos no heap sem recompilação, mas costuma executar cerca de 20 a 30 vezes mais devagar. A redução típica de velocidade do ASan é de cerca de duas vezes, com uso adicional de memória. Não combine uma versão compilada com ASan com Valgrind, MemorySanitizer ou ThreadSanitizer. Execute deliberadamente entradas de casos-limite: um erro em um caminho não executado não pode aparecer no relatório.

Uma ferramenta de verificação de memória não cobre todas as operações inválidas em C. O UndefinedBehaviorSanitizer, ou UBSan, instrumenta muitas operações aritméticas e operações com ponteiros e arranjos. Combine-o com ASan para que uma execução de teste possa detectar mais de uma classe de defeito.

Torne falhas aritméticas visíveis

Com int de 32 bits, somar dois valores de 2.000.000.000 exige um total de 4.000.000.000. Esse resultado excede INT_MAX. Um relatório do UBSan identifica o estouro de inteiro com sinal na adição e informa os operandos. Imprimir uma resposta negativa que parece ter retornado ao início da faixa sem a ferramenta não tornaria a operação válida.

Use um tipo para o total que possa representar a faixa aceita ou rejeite uma soma antes que ela cause estouro. Converter o resultado já estourado para long long é tarde demais; a própria operação deve usar um tipo adequado.

Um comando de teste comum é:

clang -std=c17 -Wall -Wextra -g -fsanitize=address,undefined -fno-omit-frame-pointer -fno-sanitize-recover=undefined program.c -o program-check

O UBSan normalmente permite a recuperação após muitos relatórios, então o código posterior pode continuar. -fno-sanitize-recover=undefined faz essas falhas interromperem o teste com um código de erro. Isso ajuda verificações automatizadas a detectar um defeito mesmo quando a saída final impressa parece correta.

Escolha a ferramenta para o defeito

A redução modular sem sinal é definida, portanto o grupo undefined não a relata. Clang tem uma verificação separada, -fsanitize=unsigned-integer-overflow, para código em que a redução modular indica um defeito. Não conclua que todo resultado inteiro indesejado é UB.

MemorySanitizer é uma ferramenta do Clang usada principalmente no Linux; bibliotecas não instrumentadas podem confundir seu rastreamento. ThreadSanitizer detecta acessos conflitantes por threads sem sincronização, com pelo menos uma escrita. Os acessos não precisam ocorrer exatamente no mesmo instante. Nenhuma das ferramentas pode ser combinada com ASan em uma única versão compilada.

Torne a verificação uma rotina

Mantenha os avisos ativados e resolva-os. Compile com ASan e UBSan e depois execute entradas vazias, entradas com um elemento, buffers cheios, texto inválido e valores próximos dos limites aceitos. Execute análise estática para inspecionar caminhos que os testes podem não alcançar e repita as verificações automaticamente quando o código mudar. Execute também a configuração de distribuição, em que as configurações de otimização e asserção são diferentes.

O teste por fuzzing fornece muitas entradas geradas ou modificadas. libFuzzer e AFL++ podem revelar caminhos incomuns em analisadores; sanitizadores transformam uma operação inválida desencadeada em um relatório útil. Salve uma entrada que encontre um defeito, reduza-a sem perder a falha, corrija a causa e mantenha-a como teste de regressão. Uma execução sem erros é evidência sobre as entradas executadas, não uma garantia para todas as execuções possíveis.

Um padrão de codificação segura reúne regras concretas que evitam defeitos recorrentes. Ele oferece a quem revisa o código perguntas mais úteis do que “Isto parece seguro?”. Cada regra conecta uma operação arriscada à condição ou ao projeto necessário para torná-la segura.

Leia uma regra para entender seu motivo

O Padrão de codificação segura em C do SEI CERT vem do Software Engineering Institute da Carnegie Mellon University. A edição em livro de 2016 é acompanhada de uma versão on-line em evolução. Ele distingue regras, cuja violação provavelmente causará defeitos, de recomendações que melhoram a confiabilidade e a segurança.

Os identificadores combinam uma categoria, um número e -C. As regras usam números de 30 a 99; as recomendações usam de 00 a 29. Por exemplo, INT32-C trata de estouro de inteiro com sinal, enquanto DCL00-C é uma recomendação sobre declarações. As categorias incluem declarações (DCL), expressões (EXP), inteiros (INT), ponto flutuante (FLP), arranjos (ARR), cadeias de caracteres (STR), memória (MEM), entrada e saída (FIO), ambiente (ENV), erros (ERR) e assuntos diversos (MSC).

A página de uma regra normalmente explica o defeito, mostra código não conforme, apresenta soluções conformes e classifica o risco. Leia as suposições de cada solução. Uma função substituta só é útil quando seu comportamento realmente atende ao requisito.

Aplique uma regra a um caminho dos dados

FIO30-C trata de cadeias de formatação. Este código trata dados externos como um programa de formatação:

printf(user_name);

Um nome de usuário que contenha conversões de formato faz printf procurar argumentos que não foram fornecidos; %n pode causar uma escrita na memória. Mantenha o formato sob controle do programa:

printf("%s", user_name);

Como alternativa, fputs(user_name, stdout) imprime o texto sem processamento de formato. -Wformat=2 inclui verificações que ajudam a encontrar formatos inseguros. A correção altera a forma como os dados são interpretados, não apenas o comprimento possível da cadeia de caracteres.

Crie uma lista de verificação útil

Para memória, pergunte se os índices permanecem dentro dos objetos (ARR30-C), se o armazenamento da cadeia inclui o terminador (STR31-C), se o armazenamento liberado nunca é acessado (MEM30-C), se as alocações sob sua responsabilidade são liberadas (MEM31-C), se apenas alocações válidas são liberadas (MEM34-C) e se bytes suficientes são alocados (MEM35-C).

Para expressões, verifique redução modular sem sinal indesejada (INT30-C), estouro de inteiro com sinal (INT32-C), divisão inválida (INT33-C), leituras de valores não inicializados (EXP33-C) e desreferenciações nulas (EXP34-C). Nos pontos de interação com bibliotecas, trate falhas relatadas (ERR33-C) e erros de conversão (ERR34-C). Evite system() conforme orienta ENV33-C, pois um shell interpreta sua entrada.

Tabelas de risco classificam gravidade, probabilidade e custo de correção de 1 a 3; uma pontuação maior de custo significa correção mais barata. O produto desses valores é a prioridade, de 1 a 27. Os níveis agrupam prioridades em L1 (12–27), L2 (6–9) e L3 (1–4). Isso ajuda a ordenar as correções sem declarar inofensivos os defeitos de menor prioridade.

Use as regras durante a revisão de código e use resultados de analisadores associados a seus identificadores. MISRA C é outro padrão usado em software embarcado crítico para a segurança. As regras ajudam a evitar defeitos, enquanto avisos, testes e sanitizadores verificam se a implementação realmente as segue. Memorizar apenas os identificadores não detecta um terminador ausente nem um ramo de erro ignorado.

A manipulação segura de cadeias de caracteres exige uma origem válida, uma capacidade conhecida do destino e uma decisão sobre o texto que não couber. Uma função com limite de tamanho evita algumas sobrescritas, mas você ainda deve verificar se toda a operação foi bem-sucedida.

Leve a capacidade junto com o ponteiro

sizeof mede o tipo de seu operando. Para um char buf[20] local, ele fornece 20 bytes. Em void fill(char buf[]), o parâmetro é ajustado para um ponteiro; sizeof buf mede esse ponteiro, não o arranjo da função chamadora. Passe um parâmetro de capacidade, como em fill(buf, sizeof buf), enquanto a função chamadora ainda tem o tipo de arranjo.

Uma cadeia com cinco caracteres precisa de seis bytes, incluindo '\0'. A capacidade conta cada byte em que se pode escrever; o comprimento da cadeia exclui o terminador. É por isso que malloc(strlen(src)) aloca um byte a menos para uma cópia.

Leia uma linha com limite

Use fgets(buf, sizeof buf, stdin) e verifique seu valor de retorno antes de usar o conteúdo. Ela armazena no máximo a capacidade menos um caracteres e depois um terminador. Ela mantém uma quebra de linha quando esta couber. Após uma leitura bem-sucedida, buf[strcspn(buf, "\n")] = '\0'; remove uma quebra de linha armazenada.

Se uma linha longa preencher o buffer, os caracteres não lidos permanecem para a próxima chamada. Decida se vai rejeitar a linha e descartar o restante, ler mais ou aceitar o truncamento. Remover uma quebra de linha não comprova que você leu a linha completa. gets não aceita uma capacidade e foi removida em C11; nunca a use.

Para uma única palavra em char name[20], %19s em scanf limita os caracteres armazenados e deixa espaço para o terminador. Verifique se o número esperado de conversões foi bem-sucedido. Para texto numérico não confiável, prefira uma linha completa seguida de strtol com verificações; %d tem comportamento indefinido quando o valor convertido não pode ser representado, mesmo que você inspecione a contagem de retorno de scanf.

Detecte uma cópia truncada

strcpy e strcat não conhecem a capacidade do destino. strncpy pode deixar o resultado sem terminador. Com uma capacidade positiva, snprintf termina o texto armazenado e informa quantos caracteres a saída completa exigiria:

char dst[8];
int r = snprintf(dst, sizeof dst, "%s", "debugging");
if (r < 0) {
    /* report encoding failure */
} else if ((size_t)r >= sizeof dst) {
    /* report truncation */
}

A cadeia armazenada é “debuggi”, e r é 9. A saída completa precisa de dez bytes, incluindo seu terminador. Verifique se o resultado é negativo antes de convertê-lo para size_t. Para que o resultado caiba, r deve ser menor que a capacidade.

Adeque a operação ao armazenamento

Use memmove quando a origem e o destino se sobrepuserem; memcpy com regiões sobrepostas é indefinido. strlcpy está disponível em sistemas BSD, macOS e glibc 2.38 em diante, mas não faz parte do ISO C. As funções do Anexo K são opcionais e não estão disponíveis em muitas bibliotecas.

Mantenha dados do usuário fora do próprio formato. Faça cada conversão corresponder a seu argumento: %d para int, %ld para long, %zu para size_t, %f para double e %s para uma cadeia terminada em nulo. %p exige um void *, portanto passe uma conversão apropriada do ponteiro. Um limite de largura não pode corrigir um tipo de argumento incompatível.

Dados externos podem ser sintaticamente válidos e ainda assim inseguros para a operação pretendida. Valide seu comprimento, formato completo e faixa útil antes que se tornem um índice, tamanho de alocação ou contagem de laço.

Analise o número inteiro

atoi não oferece uma forma confiável de distinguir um zero válido de texto inválido, e um resultado que não pode ser representado causa comportamento indefinido. strtol fornece um ponteiro de fim da conversão e um erro de faixa. Após ler uma linha completa e remover sua quebra de linha, um analisador decimal rigoroso pode usar:

errno = 0;
char *end;
long v = strtol(text, &end, 10);
if (end == text || *end != '\0' || errno == ERANGE) {
    /* reject the numeric text */
} else if (v < 0 || v > 150) {
    /* reject this application's range */
} else {
    int age = (int)v;
    /* use age */
}

Inclua <errno.h> e <stdlib.h>. O primeiro teste distingue três falhas: ausência de algarismos, texto ao final e um valor fora da faixa de long. O teste da faixa permitida pela aplicação vem antes da conversão para int. strtol aceita espaços iniciais e um sinal opcional; decida se a gramática da aplicação os permite.

Para “42abc”, a conversão pode retornar 42, mas end aponta para as letras restantes. Para “abc”, nenhum algarismo é consumido. Para um inteiro decimal grande demais, errno se torna ERANGE. Um número retornado diferente de zero, por si só, não comprova uma conversão completa nem uma faixa segura.

Preserve a responsabilidade pela liberação em caso de falha

Toda operação que pode falhar precisa de uma resposta. Verifique resultados de alocação, fopen, fgets, contagens de conversão e conclusão da saída. O retorno NULL de fgets pode significar fim da entrada ou erro de leitura. fclose pode informar uma falha de escrita de dados armazenados em buffer. Use informações de erro adequadas à função; muitas chamadas de biblioteca definem errno, que perror ou strerror pode transformar em um diagnóstico legível.

Para redimensionar para um tamanho positivo, proteja o cálculo do tamanho e a alocação original:

if (new_n == 0) {
    free(a);
    a = NULL;
} else if (new_n > SIZE_MAX / sizeof *a) {
    /* reject the size */
} else {
    int *tmp = realloc(a, new_n * sizeof *a);
    if (tmp == NULL) {
        /* handle failure; a still owns its old block */
    } else {
        a = tmp;
    }
}

Atribuir realloc diretamente ao único ponteiro responsável pela alocação faz perder o endereço do bloco antigo em caso de falha. Trate zero separadamente: C17 torna realloc com tamanho zero definido pela implementação, enquanto C23 o torna indefinido. Após um redimensionamento bem-sucedido, use o ponteiro retornado e descarte referências antigas ao mesmo objeto.

Deixe um caminho de erro claro

Uma única seção de liberação pode liberar os recursos adquiridos na ordem inversa. Inicialize com NULL os ponteiros pelos quais você é responsável, feche apenas arquivos abertos e retorne um código de falha após informar a causa. Um goto cleanup pode facilitar a análise desses caminhos.

Evite system() em tarefas que envolvam texto externo: o shell pode interpretar esse texto como comandos. Prefira uma operação de biblioteca ou uma interface adequada para iniciar programas com argumentos passados separadamente. Trate argumentos de linha de comando, valores de ambiente, conteúdo de arquivos e dados de rede como entradas que exigem o mesmo cuidado que texto digitado.

Segurança de memória significa que os acessos permanecem dentro do armazenamento que um programa tem direito de usar. C oferece controle direto da memória e deixa as verificações de limites e de tempo de vida para o programador.

Diferencie limites de tempo de vida

A segurança espacial mantém um acesso dentro dos limites de seu objeto. Escrever no elemento dez de um arranjo de dez elementos a viola. A segurança temporal mantém o acesso dentro do tempo de vida do objeto. Ler uma alocação após free, liberá-la duas vezes ou usar o endereço retornado de uma variável local viola as regras de tempo de vida.

As consequências podem ir além de um encerramento inesperado. Uma leitura pode expor dados confidenciais. Uma escrita pode corromper um arquivo, alterar dados de controle ou criar uma vulnerabilidade de segurança quando uma entrada externa controla a operação. Um programa que continua após uma corrupção pode produzir resultados convincentes, mas falsos.

Essa responsabilidade também afeta equipes experientes. A Microsoft informou em 2019 que cerca de 70% das vulnerabilidades às quais havia atribuído identificadores CVE, ano após ano por mais de uma década, diziam respeito à segurança de memória. Em dezembro de 2023, a CISA e agências parceiras recomendaram que fabricantes de software planejassem a transição para linguagens com segurança de memória. Essas são observações históricas específicas, não um percentual medido para todos os programas em C.

Entenda os motivos para escolher C

C oferece controle sobre a disposição e a alocação da memória e o acesso ao hardware, sem exigir um coletor de lixo. Seu pequeno ambiente de execução é adequado a firmware com recursos limitados. A linguagem tem amplo suporte de compiladores, grandes bases de código existentes e interfaces que muitas outras linguagens podem chamar. Esses benefícios explicam seu uso em núcleos de sistemas operacionais, software embarcado, ambientes de execução e bibliotecas.

Eles não tornam todo programa em C previsivelmente rápido: algoritmos, alocação, caches e chamadas de sistema continuam importantes. O benefício relevante é o controle sobre os custos e os requisitos do ambiente de execução.

Operações inseguras e interfaces com C exigem cuidado especial em sistemas que, de resto, oferecem segurança de memória. A segurança de memória também deixa erros de lógica e injeção por entrada para serem resolvidos.

Escolha camadas para o risco restante

Evite defeitos com regras de codificação, avisos e revisão. Detecte defeitos com análise estática, testes de casos-limite, sanitizadores e fuzzing. Limite os danos restantes com protetores de pilha, verificações compatíveis de _FORTIFY_SOURCE, randomização do leiaute do espaço de endereçamento (ASLR) e memória não executável. Uma medida de mitigação pode impedir um ataque ou transformar uma corrupção em encerramento inesperado, mantendo o defeito no código-fonte.

Os custos orientam o uso. O ASan normalmente dobra o tempo de execução e aumenta o uso de memória; o Valgrind costuma tornar a execução de 20 a 30 vezes mais lenta. Eles são mais adequados a testes do que ao uso comum em distribuição. O reforço de segurança de menor custo costuma permanecer nas versões para distribuição.

Para um novo analisador de arquivos da internet sem restrição que exija C, uma linguagem com segurança de memória reduz um risco importante. Para firmware existente em C em um microcontrolador com 32 KB de memória, o suporte à linguagem e os limites de recursos podem favorecer C com verificações rigorosas. Baseie a escolha nas restrições, na exposição a entradas e na facilidade de manutenção; a substituição gradual de um analisador arriscado também pode ser viável.