Undefined Behavior a fondo

El Undefined Behavior es la característica de C más malentendida y más importante. No es “un bug que a veces funciona”: es un contrato entre tú y el compilador que, cuando lo rompes, le da permiso para hacer literalmente cualquier cosa. Entenderlo de verdad es alcanzar la comprensión que casi nadie tiene.

Tres tipos de “no está garantizado”

El estándar C distingue con precisión:

El peligroso es el primero. Los casos clásicos de UB:

int x = INT_MAX + 1;        // desbordamiento de entero CON signo → UB
arr[10];                     // acceso fuera de límites → UB
*p;                          // dereferenciar puntero nulo/colgante → UB
int y; use(y);               // leer variable no inicializada → UB
1 << 40;                     // desplazar más que el ancho del tipo → UB
a / 0;                       // división por cero → UB
// data race entre hilos sin sincronizar → UB

El compilador EXPLOTA el UB

Aquí está la parte que asombra y aterra a partes iguales. El compilador no solo “no define qué pasa”: asume que el UB nunca ocurre y optimiza basándose en esa suposición. Esto puede hacer desaparecer tu código:

int f(int x) {
    if (x + 1 < x)          // desbordamiento con signo es UB...
        return manejar_overflow();  // ...así que el compilador asume
    return normal(x);               // que x+1 < x NUNCA es cierto
}
// el compilador ELIMINA la comprobación entera: "eso no puede pasar"

Por qué el estándar permite el UB

No es maldad: es rendimiento. Si el estándar obligara a comprobar cada acceso a array, cada desbordamiento, cada puntero, C sería tan lento como los lenguajes con recolector de basura y comprobaciones en runtime. El UB es el precio de la velocidad: el estándar dice “prometemos comportamiento correcto solo si tú prometes no hacer estas cosas”. El compilador confía en esa promesa para generar código óptimo. Rompe la promesa, y el trato se cancela.

Cómo defenderte