La filosofía: confianza en el programador

El principio rector de C está escrito con todas las letras en el documento de fundamentos del estándar: confiar en el programador. Suena a permiso, y esa lectura ha costado miles de vulnerabilidades. En realidad es lo contrario: no es una licencia que se te concede, es una obligación de prueba que asumes. Entender esa inversión es el salto conceptual más importante del nivel uno.

El espíritu de C: cinco principios incómodos

El documento de fundamentos que acompaña al estándar recoge un puñado de máximas que el comité usa para decidir qué entra y qué no. Vale la pena leerlas literalmente, porque explican decisiones que de otro modo parecen arbitrarias:

• Confía en el programador. El lenguaje no impone comprobaciones que el programador podría no necesitar.
• No impidas al programador hacer lo que hay que hacer. Si algo es necesario a bajo nivel, debe ser expresable.
• Mantén el lenguaje pequeño y simple. La complejidad se paga en la implementación, y la implementación debe ser portable.
• Ofrece una única forma de hacer cada operación. Se ha erosionado con el tiempo, pero sigue orientando.
• Hazlo rápido, aunque no se garantice portable. El rendimiento pesa más que la uniformidad entre plataformas.

Los tres primeros forman una unidad lógica. Si el lenguaje debe ser pequeño y simple, el compilador puede ser pequeño y simple; si el compilador es simple, existe para cualquier arquitectura nueva; si existe para cualquier arquitectura, C se convierte en el sustrato universal que viste en el nivel 1.3. La ausencia de protecciones no es un olvido: es el precio pagado deliberadamente por la ubicuidad.

Qué se gana: el modelo de ejecución transparente

La contrapartida es un modelo mental que casi ningún otro lenguaje de uso general ofrece con esta nitidez:

Estas cuatro propiedades no son independientes: todas derivan de la misma renuncia. El lenguaje no puede protegerte precisamente porque no se reserva ninguna capa intermedia donde colocar la protección.

Qué se pierde: el comportamiento indefinido como mecanismo

Aquí está la parte que casi nadie explica bien. El estándar define el significado de un programa solo si el programa es correcto. Si invocas comportamiento indefinido, la norma no dice que el resultado sea impredecible: dice que la norma no impone ningún requisito, y el compilador puede asumir con total legitimidad que eso jamás ocurre.

Esa asunción no es pasiva. El optimizador la usa como premisa para razonar:

#include <limits.h>

/* Comprobación rota: se apoya en el desbordamiento con signo, que es UB */
int suma_saturada(int a, int b)
{
    int r = a + b;
    if (a > 0 && b > 0 && r < 0)   /* el compilador puede eliminar esta rama */
        return INT_MAX;
    return r;
}

El razonamiento del compilador es impecable. Como el desbordamiento con signo es comportamiento indefinido, en todo programa válido a + b no desborda; si a y b son positivos, entonces r es positivo; por tanto la condición es siempre falsa y la rama es código muerto. Tu comprobación desaparece, y desaparece más agresivamente cuanto más optimices.

La versión correcta no pregunta después, sino antes, y no usa aritmética que pueda desbordar:

#include <limits.h>

int suma_saturada_ok(int a, int b)
{
    if (b > 0 && a > INT_MAX - b) return INT_MAX;
    if (b < 0 && a < INT_MIN - b) return INT_MIN;
    return a + b;
}

El patrón general es el mismo en todo C: nunca compruebes una condición después de haber ejecutado la operación que la haría indefinida. Una vez cruzada esa línea, no hay estado del programa sobre el que razonar.

El mismo mecanismo aparece, con consecuencias mucho peores, cuando la premisa es la validez de un puntero:

int leer_campo(struct nodo *n)
{
    int v = n->valor;      /* desreferencia: el compilador deduce que n no es nulo */
    if (n == NULL)         /* comprobacion ahora demostrablemente inutil */
        return -1;
    return v;
}

Al desreferenciar n en la primera línea, el programa afirma implícitamente que n no es nulo, porque desreferenciar un puntero nulo es indefinido. El optimizador propaga esa afirmación hacia abajo y elimina la comprobación. Este patrón exacto ha producido vulnerabilidades reales en núcleos de sistemas operativos: una comprobación defensiva que el autor escribió, que el revisor leyó y que el binario no contiene.

flowchart TD
A[Escribes una operacion con comportamiento indefinido] --> B[La norma no impone ningun requisito]
B --> C[El compilador asume que jamas ocurre]
C --> D[Convierte la asuncion en premisa del analisis]
D --> E[Elimina ramas y reordena accesos]
E --> F[El binario no contiene tu comprobacion]
F --> G[El fallo aparece lejos de la causa]
style B fill:#f9e2af,color:#11111b
style D fill:#fab387,color:#11111b
style G fill:#f38ba8,color:#11111b

El contrato que firmas al compilar

Formulado sin adornos, cada compilación es un intercambio con dos cláusulas asimétricas:

• Tú te comprometes a que, para toda entrada posible, tu programa no invoca comportamiento indefinido: sin accesos fuera de rango, sin uso después de liberar, sin desbordamiento con signo, sin violaciones de alias estricto, sin carreras de datos, sin desreferenciar punteros nulos.
• El compilador se compromete a generar el código más rápido posible suponiendo que cumpliste. Nada más. No te avisa si fallas, no está obligado a diagnosticarlo y no hay un modo de fallo definido.

La consecuencia metodológica es que el contrato debe escribirse, no suponerse. Una interfaz profesional en C declara sus precondiciones y su régimen de propiedad de forma explícita, porque el lenguaje no tiene dónde expresarlas:

/*
 * Copia como maximo cap-1 bytes de src en dst y termina en cero.
 * Precondiciones: dst apunta a al menos cap bytes validos; cap es mayor que 0;
 *                 src es una cadena valida terminada en cero; no se solapan.
 * Devuelve: longitud que habria necesitado, para detectar truncamiento.
 * Propiedad: el llamante posee dst; la funcion no retiene ningun puntero.
 */
size_t copiar_acotado(char *dst, size_t cap, const char *src);

Ese bloque no es documentación decorativa: es la enumeración exacta de lo que el compilador da por cierto y no puede verificar. Si una sola de esas líneas se incumple en alguna ruta de ejecución, el programa deja de tener significado definido.

La asimetría es total: tu parte es una obligación universal sobre todas las ejecuciones posibles, y la suya está condicionada a que la tuya se cumpla. Por eso conviene pensarlo en términos de demostración y no de buenas intenciones. La práctica profesional en 2026 consiste en tener un procedimiento explícito para descargar esa obligación: avisos del compilador tratados como errores, sanitizers de memoria y de comportamiento indefinido en las pruebas, análisis estático en la integración continua y fuzzing sobre cualquier entrada no confiable. Todo eso lo verás a fondo en los niveles 24 a 26.