Análisis estático y fuzzing

Los sanitizers cazan bugs cuando el código se ejecuta con una entrada dada. Pero ¿y los bugs en caminos que tus tests no recorren? Para eso están dos familias complementarias: el análisis estático, que examina el código sin ejecutarlo, y el fuzzing, que bombardea tu programa con millones de entradas para encontrar las que lo rompen.

Análisis estático

Un analizador estático lee tu código y razona sobre todos los caminos posibles, señalando bugs potenciales sin ejecutar nada:

# el analizador integrado en GCC
gcc -std=c23 -fanalyzer -Wall prog.c

# clang-tidy: cientos de checks (bugs, estilo, modernización)
clang-tidy prog.c -- -std=c23

# cppcheck: analizador dedicado, fácil de integrar
cppcheck --enable=all prog.c

Detectan cosas que el compilador normal no: dobles frees en ciertos caminos, punteros nulos condicionales, fugas en ramas de error, uso de memoria liberada. Como examinan todos los caminos (no solo los que tus tests ejecutan), encuentran bugs latentes.

Valgrind

Valgrind (su herramienta Memcheck) ejecuta tu programa en una máquina virtual que vigila cada acceso a memoria. Más lento que ASan pero no requiere recompilar y detecta cosas distintas:

valgrind --leak-check=full ./prog
# informa de accesos inválidos, memoria no inicializada y fugas exactas

Fuzzing: el que encuentra lo que no imaginaste

El fuzzing alimenta tu programa con entradas generadas automáticamente —millones, guiadas por cobertura de código— buscando las que provocan un crash o un fallo de sanitizer. Descubre casos límite que ningún humano escribiría como test:

// objetivo de libFuzzer: recibe datos arbitrarios y los procesa
int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    parsear(data, size);   // tu función bajo prueba
    return 0;
}

clang -std=c23 -fsanitize=fuzzer,address parser_fuzz.c -o fuzzer
./fuzzer          # genera entradas sin parar hasta encontrar un crash

Las tres técnicas se complementan