Puntos de secuencia y orden de evaluación

Casi todo programador cree que una expresión se evalúa de izquierda a derecha. C nunca prometió tal cosa. El estándar define un orden parcial, no total, sobre las evaluaciones dentro de una expresión, y deja libertad al compilador para reordenar, intercalar y elegir. Cuando escribes código que depende de un orden que el estándar no fija, no obtienes un resultado arbitrario pero razonable: obtienes comportamiento indefinido, con licencia total del optimizador para asumir que ese caso nunca ocurre.

De puntos de secuencia a relaciones de secuenciación

Hasta C99, el estándar hablaba de puntos de secuencia: instantes en la ejecución donde todos los efectos laterales anteriores se han completado y ninguno de los posteriores ha empezado. El modelo era intuitivo pero insuficiente para describir la concurrencia, así que C11 lo reformuló en términos de una relación llamada secuenciado antes, un orden parcial estricto sobre las evaluaciones. C23 conserva ese modelo sin cambios sustanciales.

Toda evaluación tiene dos componentes que conviene separar mentalmente: el cálculo del valor, que produce el resultado, y el efecto lateral, que modifica un objeto, un fichero o el entorno. Dos evaluaciones pueden estar secuenciadas una antes de otra, secuenciadas de forma indeterminada —ocurren en algún orden, pero sin intercalarse— o simplemente no secuenciadas, que es el caso peligroso, porque el compilador puede intercalar sus pasos libremente.

De ahí sale la regla que lo gobierna todo. Si sobre un mismo objeto escalar hay dos efectos laterales no secuenciados entre sí, o hay un efecto lateral no secuenciado respecto a un cálculo de valor que usa ese mismo objeto, el comportamiento es indefinido.

Los ejemplos que son indefinidos

Estos patrones no son curiosidades académicas: aparecen en código real, compilan sin errores y producen resultados distintos según el compilador, la arquitectura y el nivel de optimización.

int i = 0, a[10];

i = i++;             /* UB: dos efectos laterales sobre i, no secuenciados */
i = ++i + 1;         /* UB: igual, la asignacion y el incremento compiten  */
a[i] = i++;          /* UB: el efecto sobre i no esta secuenciado respecto
                        al calculo del valor de i que indexa a             */
i = i++ + ++i;       /* UB clasico de examen, y triplemente mal            */
printf("%d %d", i++, i++);   /* UB: dos efectos sobre i entre argumentos   */
f(i, i++);           /* UB: el argumento que lee i no esta secuenciado
                        respecto al que lo modifica                        */

Todos comparten la misma estructura: el objeto i recibe una modificación cuyo momento no está fijado respecto a otro acceso al mismo objeto. Compara con las versiones correctas, que resultan estar bien por razones muy concretas del estándar:

i = i + 1;           /* correcto: un solo efecto lateral sobre i          */
i++;  i = a[i];      /* correcto: el punto y coma separa las expresiones  */
i = (i++, i);        /* correcto: la coma secuencia el izquierdo antes    */
a[i++] = 0;          /* correcto: un solo acceso y un solo efecto sobre i */

Indefinido frente a no especificado

Esta distinción es la que separa una lectura superficial del estándar de una lectura profesional, y tiene consecuencias prácticas directas sobre qué código es aceptable y cuál no.

Comportamiento indefinido significa que el estándar retira todas las garantías sobre el programa entero, no solo sobre esa expresión. Comportamiento no especificado significa que hay un conjunto finito de posibilidades válidas, el compilador elige una y no está obligado a documentarla ni a ser consistente, pero el programa sigue siendo un programa correcto en el resto de sus aspectos.

/* NO ESPECIFICADO: el orden de las llamadas no esta fijado,
   pero no se intercalan y el programa es valido            */
int total = leer_sensor() + leer_reloj();

/* INDEFINIDO: dos efectos laterales sobre el mismo objeto
   sin secuenciacion entre ellos                            */
int x = contador++ + contador++;

En el primer caso, si ambas funciones tienen efectos laterales sobre un estado global compartido, el resultado depende del orden elegido, y ese orden es asunto del compilador. El programa no es incorrecto en sentido formal, pero sí es no determinista, lo que en un sistema que debe ser reproducible equivale a un defecto. En el segundo caso el programa no tiene ningún significado y cualquier cosa puede ocurrir.

flowchart TD
A[Dos accesos al mismo objeto escalar en una expresion] --> B[Hay al menos un efecto lateral]
B --> C[Estan secuenciados por punto y coma coma cortocircuito o ternario]
B --> D[No estan secuenciados entre si]
C --> E[Comportamiento definido y determinista]
D --> F[Comportamiento indefinido y el optimizador puede asumir que no ocurre]
style E fill:#a6e3a1,color:#11111b
style F fill:#f38ba8,color:#11111b

Merece la pena señalar un contraste histórico. C++17 endureció sus reglas: fijó el orden de los operandos de << y >>, del subíndice y de la asignación, y dejó el orden de los argumentos de una llamada como no especificado pero sin intercalación. C no ha adoptado esos cambios, ni en C17 ni en C23. Código que un compilador de C++ moderno acepta con semántica definida sigue siendo indefinido al compilarlo como C, y esa asimetría atrapa con regularidad a quien alterna entre ambos lenguajes.

Cómo escribir código inmune

La defensa no consiste en memorizar la lista de patrones prohibidos, sino en adoptar tres hábitos que hacen imposible construirlos.

El primero es la regla del efecto único: como máximo un efecto lateral por expresión completa. Si una expresión contiene un ++, un -- o una asignación, que sea el único, y que el objeto modificado no aparezca en ningún otro lugar de esa misma expresión. Es una regla mecánica, verificable de un vistazo en revisión de código.

El segundo es separar en sentencias. Una línea que hace dos cosas se convierte en dos líneas que hacen una cada una, y el punto y coma introduce la secuenciación que el estándar sí garantiza. El coste en legibilidad es nulo o negativo, y el coste en rendimiento es exactamente cero: el compilador genera el mismo código, porque la reordenación que tú te prohíbes escribir él la sigue teniendo permitida internamente mientras el resultado observable no cambie.

/* Antes: densidad que oculta la indefinicion */
buffer[indice] = indice++;

/* Despues: dos sentencias, orden garantizado, intencion evidente */
buffer[indice] = indice;
indice++;

El tercero es activar los avisos. GCC implementa -Wsequence-point, incluido en -Wall; Clang implementa -Wunsequenced, más agresivo y con mejor cobertura de casos con punteros. Ninguno detecta todos los casos —el problema es indecidible en general, sobre todo a través de punteros o llamadas—, pero cazan la práctica totalidad de los patrones escritos a mano.

Queda un cuarto frente que los avisos no cubren: las macros. Una macro que use su parámetro dos veces evalúa dos veces la expresión que le pases, y si esa expresión tiene un efecto lateral el resultado deja de ser el que el autor de la macro imaginó.

#define MAX(a, b)  ((a) > (b) ? (a) : (b))

int m = MAX(i++, limite);   /* i puede incrementarse una o dos veces */

Aquí no hay comportamiento indefinido —el ternario secuencia correctamente— pero sí un número de incrementos que depende de qué rama gane, lo cual es igual de indeseable. La defensa clásica es evaluar cada parámetro una sola vez en una variable temporal usando typeof, que C23 estandariza precisamente para esto, y la defensa mejor es sustituir la macro por una función static inline, donde los argumentos se evalúan exactamente una vez por definición del lenguaje.