Convivir con el UB

Erradicar el comportamiento indefinido no es una aspiración moral: es una tarea de ingeniería con herramientas concretas, costes medibles y decisiones que hay que tomar por escrito. Esta lección cierra el nivel con lo operativo: qué te promete tu compilador más allá de la norma, qué compras realmente con cada bandera defensiva, y una disciplina de siete reglas que hace que el problema deje de aparecer en código nuevo.

Lo que tu compilador promete por encima de la norma

La norma es el mínimo común. Cada implementación define más de lo que la norma exige, lo documenta en su manual y se compromete a mantenerlo. Esa documentación es un contrato real, y usarla conscientemente es legítimo; usarla sin saber que la estás usando es lo que produce código que muere al cambiar de compilador.

Dos precisiones que decidan bien el uso de estas garantías. La primera: una extensión documentada no convierte tu programa en conforme, lo hace correcto para esa implementación; si algún día compilas con otra, el contrato desaparece sin aviso. La segunda: nada de esto aplica a las construcciones verdaderamente indefinidas como el acceso fuera de rango o el uso de memoria liberada, para las que ningún compilador ofrece garantía alguna, porque no hay comportamiento razonable que prometer.

La conclusión práctica es que las extensiones sirven para dos cosas y solo dos: sostener bases de código heredadas que no puedes reauditar, y construir un dialecto explícito para un proyecto que controla su propia cadena de compilación. Nunca para justificar código nuevo.

Merece la pena mirar el caso del kernel con atención, porque es el único ejemplo a gran escala de la segunda vía hecha bien. No eligió sus tres banderas por comodidad ni por no querer arreglar el código: las eligió porque su modelo de programación —estructuras reinterpretadas a través de tipos distintos, punteros derivados por aritmética sobre desplazamientos, la página cero deliberadamente no mapeable— hace que ciertas hipótesis del optimizador sean falsas por diseño. Y las escribió en su sistema de compilación, no en un correo. Ese es el estándar al que hay que llegar antes de permitirse una bandera defensiva: saber exactamente qué hipótesis retiras, por qué es falsa en tu dominio, y dejarlo por escrito donde el siguiente lo encuentre.

Las banderas que domestican, y su precio

Cada bandera defensiva hace una cosa concreta: retira una hipótesis al optimizador. Eso define el comportamiento y, en la misma medida, cuesta rendimiento. Ninguna arregla nada; todas compran previsibilidad con velocidad, y saber cuál hipótesis retira cada una es la diferencia entre una decisión de ingeniería y un amuleto copiado de un foro.

# define el desbordamiento con signo como envolvente en complemento a dos
gcc -fwrapv prog.c

# como fwrapv pero solo desactiva las optimizaciones que lo asumen
gcc -fno-strict-overflow prog.c

# retira la regla de aliasing estricto: cualquier puntero puede alias de otro
gcc -fno-strict-aliasing prog.c

# no elimina comprobaciones de nulidad por dereferencias previas
gcc -fno-delete-null-pointer-checks prog.c

# los bucles sin efectos observables ya no se asumen terminantes
gcc -fno-finite-loops prog.c

# char sin signo en todas las plataformas, y aritmetica de punteros acotada
gcc -funsigned-char -fno-wrapv-pointer prog.c

flowchart TD
A[Que hago con este comportamiento indefinido] --> B[Es codigo nuevo que yo escribo]
A --> C[Es codigo heredado que no puedo reauditar]
B --> D[Corregir el origen: aritmetica comprobada, memcpy, validar antes]
C --> E[Bandera defensiva y anotar la deuda tecnica]
D --> F[Verificar con UBSan en la bateria de pruebas]
E --> F
F --> G[Fijar la bandera en el sistema de compilacion, no en la memoria]
style D fill:#a6e3a1,color:#11111b
style E fill:#f9e2af,color:#11111b
style G fill:#89b4fa,color:#11111b

-fwrapv es la más útil y la más malentendida. No hace que tu programa sea correcto: hace que el desbordamiento tenga un resultado definido y, sobre todo, impide que el optimizador razone a partir de su ausencia, que es donde estaba el peligro real. El coste es medible en bucles con contadores con signo, porque el compilador ya no puede ensanchar el índice a la palabra nativa ni vectorizar con la misma libertad; en código de propósito general es ruido y en núcleos numéricos puede ser un factor.

La diferencia con -fno-strict-overflow es sutil y conviene tenerla clara: la primera define el resultado como envolvente, de modo que puedes escribir código que dependa de ello; la segunda se limita a desactivar las optimizaciones que asumen la ausencia de desbordamiento, sin prometerte un valor. Si solo quieres protegerte del optimizador, la segunda basta y cuesta algo menos. Si además vas a apoyarte en el envolvimiento, necesitas la primera y estás escribiendo un dialecto, no C conforme.

-fno-strict-aliasing es la más cara de todas, y por una razón que se olvida: no se paga en las funciones problemáticas sino en todo el módulo. Al retirar la hipótesis, cada escritura a través de un puntero obliga al compilador a descartar lo que tuviera cacheado en registros sobre cualquier otro puntero, lo que bloquea el movimiento de código y la vectorización de bucles que no tenían nada que ver con el problema. Actívala si administras código heredado que reinterpreta memoria de forma sistemática; para código nuevo la respuesta siempre es memcpy.

Las herramientas, en orden de rentabilidad

Ninguna herramienta encuentra todo el comportamiento indefinido, y ninguna es prescindible. Se complementan porque atacan el problema desde ángulos distintos: unas razonan sobre el texto, otras observan la ejecución, y una tercera genera las entradas que las demás nunca probaron. La razón de fondo es que detectar comportamiento indefinido en general es indecidible, así que toda herramienta elige entre callar de más o avisar de más, y solo el conjunto cubre el hueco.

# 1. avisos: coste cero, cazan lo trivial y lo estatico
gcc -std=c23 -Wall -Wextra -Wpedantic -Wshadow -Wconversion \
    -Wstrict-aliasing=2 -Wnull-dereference -Warray-bounds=2 -c prog.c

# 2. sanitizers: la red principal, en toda la bateria de pruebas
gcc -std=c23 -O1 -g -fsanitize=address,undefined \
    -fno-sanitize-recover=all -fno-omit-frame-pointer prog.c -o prog

# 3. analisis estatico: razona sobre caminos que las pruebas no recorren
clang --analyze prog.c
gcc -fanalyzer -c prog.c

# 4. fuzzing: genera las entradas que nadie escribio a mano
clang -std=c23 -g -fsanitize=fuzzer,address,undefined objetivo.c -o objetivo

Hay un hueco que ninguna de las cuatro cubre y conviene nombrarlo para no vivir con una falsa sensación de seguridad: las violaciones de aliasing estricto y los incumplimientos de restrict. La primera se detecta solo parcialmente y de forma heurística mediante avisos; la segunda no la detecta absolutamente nada, porque la promesa se hace en la definición de la función y se rompe en el punto de llamada, muchas veces en otra unidad de traducción. Para esas dos, la única defensa es la disciplina de la sección siguiente.

El orden importa. Los avisos son gratis y deben estar en cero desde el primer día, con -Werror en integración continua. Los sanitizers son la red principal, pero solo ven lo que la ejecución alcanza: sin una batería de pruebas que cubra los caminos interesantes, UBSan no encuentra nada. El análisis estático cubre justamente el hueco contrario —caminos no ejecutados— a cambio de falsos positivos que hay que triar. Y el fuzzing cierra el círculo generando las entradas patológicas que ningún humano escribe, razón por la cual la combinación de fuzzing con sanitizers es, con diferencia, la que más comportamiento indefinido ha encontrado en la historia reciente del lenguaje.

Una disciplina de siete reglas

El objetivo no es cazar comportamiento indefinido: es que no llegue a escribirse. Las herramientas son la segunda línea, y una segunda línea que trabaja mucho es señal de que la primera no existe. Siete hábitos cubren la práctica totalidad de los casos reales, y todos son gratis en tiempo de ejecución porque actúan sobre cómo escribes, no sobre lo que se genera.

1. Valida antes de dereferenciar. Nunca leas a través de un puntero antes de haber comprobado su procedencia, ni siquiera para inicializar una variable que aún no usas.
2. No provoques la operación para inspeccionar su resultado. Comprueba antes con ckd_add, ckd_sub y ckd_mul, o calcula en un tipo más ancho.
3. Usa tipos sin signo para tamaños y desplazamientos, con signo para aritmética que resta. El envolvimiento sin signo está definido; la resta de tamaños que se vuelve astronómica es un bug igual de real.
4. Reinterpreta bits solo con memcpy o con una unión. Un cast entre punteros de tipos incompatibles para leer lo que otro tipo escribió es siempre una violación.
5. Un efecto colateral por expresión. Si una variable se modifica en una expresión, que no aparezca en ninguna otra parte de esa misma expresión.
6. Anula el puntero tras liberar y no reutilices nombres. El valor de un puntero liberado es indeterminado incluso sin dereferenciarlo.
7. Documenta y verifica cada dependencia de la implementación con static_assert, para que la compilación falle el día que la plataforma cambie en lugar de fallar el programa.

Ninguna de las siete pide heroísmo ni ralentiza el desarrollo. Cuatro de ellas son puramente sintácticas y se aplican sin pensar en cuanto se convierten en costumbre; las otras tres exigen preguntarse de dónde viene un valor, que es la pregunta que de todos modos hay que hacerse para escribir código correcto. El rendimiento tampoco sufre: la aritmética comprobada de stdckdint.h compila a la instrucción de suma que ya usabas más un salto sobre la bandera de acarreo, y memcpy con tamaño constante no genera llamada alguna.

Estas siete no cubren la concurrencia, que merece su propio tratado: la carrera de datos entre hilos sin sincronizar es comportamiento indefinido con las mismas consecuencias que todo lo anterior, y la única herramienta que la caza de forma sistemática es -fsanitize=thread, incompatible con el sanitizer de direcciones y por tanto con una ejecución de pruebas propia. Añádela como octava regla en cuanto tu programa tenga más de un hilo: toda variable compartida es atómica, o está protegida por un mutex, o no es compartida.