Como el optimizador te castiga

Hasta aquí el comportamiento indefinido parecía un problema de resultados raros. No lo es. Su forma más peligrosa es la contraria: el programa da resultados perfectamente normales durante años, hasta que una versión nueva del compilador aplica un paso de optimización más agresivo y elimina la comprobación de seguridad que sí escribiste. Esta lección son cuatro autopsias de código real donde ocurrió exactamente eso.

El silogismo del optimizador

El compilador no persigue a nadie. Ejecuta un razonamiento de tres pasos que es lógicamente impecable y cuya premisa mayor se la concede la propia norma.

flowchart TD
A[Premisa mayor: un programa conforme nunca ejecuta comportamiento indefinido] --> C
B[Premisa menor: esta rama solo se alcanza si hubo comportamiento indefinido] --> C
C[Conclusion: la rama es inalcanzable y puede eliminarse]
C --> D[Se borra la comprobacion escrita por el programador]
D --> E[El codigo generado no se parece al codigo fuente]
style A fill:#89b4fa,color:#11111b
style C fill:#f9e2af,color:#11111b
style E fill:#f38ba8,color:#11111b

La premisa mayor no es una interpretación abusiva: es lo que significa que la norma no imponga requisitos. Si el compilador estuviese obligado a generar código correcto también para las entradas que provocan comportamiento indefinido, entonces ese comportamiento estaría definido. La premisa menor la aporta el análisis de flujo, que es cada año más listo. Y la conclusión, que en cualquier otro contexto llamaríamos eliminación de código muerto, aquí borra precisamente las líneas defensivas.

Conviene nombrarlo bien porque cambia la actitud: el optimizador no rompe tu código. Deduce a partir de premisas que tú firmaste al escribir la construcción indefinida.

Caso uno: la comprobación de nulo que desapareció

El ejemplo canónico vive en el kernel de Linux, en el controlador tun, y produjo una escalada de privilegios explotable. El patrón, reducido a su esqueleto, era este:

static unsigned int tun_chr_poll(struct file *file, poll_table *wait)
{
    struct tun_file *tfile = file->private_data;
    struct tun_struct *tun = __tun_get(tfile);
    struct sock *sk = tun->sk;          /* 1. dereferencia de tun */

    if (!tun)                            /* 2. comprobacion de nulidad */
        return POLLERR;
    /* ... uso de sk ... */
}

El razonamiento del compilador es el silogismo aplicado al pie de la letra. La línea 1 dereferencia tun. Si tun fuese nulo, esa dereferencia sería comportamiento indefinido. Un programa conforme no ejecuta comportamiento indefinido, luego tun no es nulo en la línea 1. Como tun no se modifica entre las dos líneas, tampoco es nulo en la línea 2, luego la condición es siempre falsa, luego el if completo es código muerto y se elimina.

El resultado no fue un fallo: fue un acceso a la dirección cero que en el kernel, con la página cero mapeable por el usuario en aquella configuración, se convirtió en ejecución de código arbitrario. La comprobación estaba escrita, había pasado la revisión de código y no existía en el binario.

Caso dos: la comprobación de desbordamiento que se pliega a una constante

El segundo patrón afecta a código de validación escrito con la mejor intención. Estas cuatro funciones son intentos razonables de detectar un desbordamiento con signo, y las cuatro son eliminadas o reducidas a una constante:

/* 1. se pliega a return 1: el optimizador sabe que x+1 nunca es menor que x */
int comprobar_a(int x) { return x + 1 > x; }

/* 2. la rama de error se borra entera */
int comprobar_b(int x, int y) {
    int s = x + y;
    if ((x > 0 && y > 0 && s < 0) || (x < 0 && y < 0 && s > 0))
        return -1;                  /* inalcanzable segun el optimizador */
    return s;
}

/* 3. el bucle se convierte en aritmetica de 64 bits o se declara infinito */
void recorrer(int n) {
    for (int i = 0; i <= n; i++)    /* asume que i nunca envuelve */
        trabajo(i);
}

/* 4. UB si len es grande: el producto desborda antes de compararse */
void *reservar(int n, int len) {
    if (n * len > LIMITE) return NULL;
    return malloc(n * len);
}

El caso tres merece detenerse. La norma dice que un bucle cuya condición de control no es una expresión constante y que no realiza operaciones observables puede ser asumido terminante por la implementación. Combinado con la ausencia de envolvimiento en la aritmética con signo, el compilador deduce que i alcanza n y sale, lo que le permite ensanchar el contador a la palabra nativa y vectorizar. Si n es INT_MAX, el bucle real jamás termina y el generado hace cualquier otra cosa.

Los cuatro se arreglan con la misma disciplina: no provoques la operación para después inspeccionar su resultado. Comprueba antes, o calcula en un tipo que no pueda desbordar, o usa stdckdint.h.

#include <stdckdint.h>
#include <stdlib.h>

void *reservar_bien(size_t n, size_t len) {
    size_t total;
    if (ckd_mul(&total, n, len) || total > LIMITE) return NULL;
    return malloc(total);
}

Caso tres: el viaje en el tiempo

La consecuencia más contraintuitiva, y la que separa a quien ha entendido el asunto de quien cree haberlo entendido, es que el comportamiento indefinido no respeta la flecha del tiempo. Como la norma no impone requisitos sobre la ejecución completa —no sobre la ejecución a partir de cierto punto—, un compilador conforme puede mover efectos observables anteriores a la construcción indefinida, o eliminarlos.

#include <stdio.h>

int dividir(int a, int b) {
    printf("voy a dividir\n");   /* efecto observable, ANTES de la division */
    return a / b;                /* UB si b es cero */
}

Si llamas a esta función con b igual a cero, no tienes derecho a que el mensaje aparezca. El compilador puede razonar que la única forma de alcanzar la división con b a cero es un programa no conforme, propagar esa conclusión hacia atrás, y decidir que la llamada entera es inalcanzable —eliminando la impresión— o reordenar la salida por almacenamiento intermedio y morir antes del vaciado. Esto tiene consecuencias prácticas inmediatas: la última línea que imprime tu programa no marca dónde estaba cuando falló.

Un segundo efecto de la misma familia es la propagación por funciones ya integradas. Cuando el optimizador integra una función que en alguna rama tiene comportamiento indefinido, las conclusiones extraídas de esa rama viajan al cuerpo del llamador y pueden borrar comprobaciones escritas a cientos de líneas de distancia, en otro archivo, incorporadas por optimización en tiempo de enlace.