Macros con argumentos: paréntesis, evaluación múltiple y do while 0

Una macro con argumentos se parece tanto a una función que casi todo el mundo la escribe como si lo fuera, y ahí empiezan los problemas. El preprocesador no conoce la precedencia de operadores, no conoce los tipos y no sabe qué es un efecto secundario: solo sabe pegar el texto que le diste donde aparece el parámetro. Las tres reglas clásicas —paréntesis obligatorios, evaluación única y do ... while 0— no son manías de estilo, son la reconstrucción manual de todo lo que una función te daba gratis.

La sustitución es textual, y por eso hacen falta paréntesis

Antes de nada, una trampa de sintaxis: la lista de parámetros debe ir pegada al nombre. Si escribes un espacio entre el identificador y el paréntesis de apertura, defines una macro de objeto cuyo cuerpo empieza por un paréntesis, no una macro de función. El compilador no protesta y el resultado es incomprensible.

Con la definición correcta, el peligro real es que el preprocesador pega texto crudo y el analizador sintáctico lo reagrupa después según la precedencia. Eso rompe la expresión por dos sitios distintos, y por eso los paréntesis van en dos niveles.

#define DOBLE(x) 2*x
DOBLE(1 + 2)        /* -> 2*1 + 2 = 4, no 6: el argumento se parte */

#define DOBLE(x) 2*(x)
10/DOBLE(5)         /* -> 10/2*(5) = 25, no 1: el resultado se absorbe */

#define DOBLE(x) (2*(x))   /* correcto en ambos contextos */

El paréntesis interno protege al argumento de los operadores del cuerpo de la macro; el paréntesis externo protege al cuerpo de los operadores que rodean la invocación. Omitir cualquiera de los dos deja un fallo latente que solo aparece cuando alguien usa la macro en un contexto que tú no probaste, normalmente meses después.

Hay una tercera fractura que los paréntesis no arreglan solos. El preprocesador separa los argumentos por comas de nivel superior, así que cualquier coma no encerrada en paréntesis parte el argumento en dos. Una llamada con un inicializador entre llaves o con un tipo que lleve coma falla con un mensaje de aridad que no dice nada útil; la defensa es envolver el argumento en el punto de uso o declarar la macro variádica y usar __VA_ARGS__.

Evaluación múltiple: el defecto que no se ve

Si un parámetro aparece dos veces en el cuerpo, el argumento se escribe dos veces, y con él todos sus efectos secundarios. Esto no es una ineficiencia: es comportamiento indefinido cuando el argumento modifica un objeto, y es una llamada duplicada cuando el argumento es una función.

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

int i = 0, j = 5;
int m = MAX(i++, j);        /* i se modifica dos veces: UB */
int n = MAX(consulta(), 0); /* consulta se ejecuta dos veces */

El segundo caso es el más insidioso porque el programa es correcto y solo va lento, o correcto salvo que consulta lleve un contador o lea de un socket. Ninguna advertencia estándar lo detecta, porque desde el punto de vista del compilador ahí hay dos llamadas legítimas.

C23 mejora la situación al estandarizar typeof y typeof_unqual, que permiten declarar variables temporales con el tipo del argumento sin conocerlo. Con la extensión de expresiones-sentencia de GCC y Clang, eso da una macro que evalúa una sola vez y no fija tipos; sin ella, el remedio portable es una función.

/* extension de GCC y Clang, no estandar: expresion-sentencia */
#define MAX_SEGURO(a, b)                    \
    ({ typeof(a) _a = (a);                  \
       typeof(b) _b = (b);                  \
       _a > _b ? _a : _b; })

/* portable y preferible cuando los tipos son conocidos */
static inline int max_i(int a, int b) { return a > b ? a : b; }

Fíjate en el detalle de higiene: los temporales llevan un prefijo poco probable. Si la macro declarase a y b, cualquier invocación cuyo argumento mencione una variable con ese nombre quedaría capturada por la declaración interna. El preprocesador no tiene ámbitos, así que la higiene léxica hay que fabricarla a mano con nombres feos.

Conviene añadir aquí una regla del estándar que rara vez se enseña y que explica comportamientos aparentemente mágicos. Mientras se expande una macro, su propio nombre queda marcado como no reemplazable dentro del resultado: si el cuerpo vuelve a mencionarla, esa aparición se deja tal cual y no se expande otra vez. La consecuencia es que las macros no pueden ser recursivas y que la construcción #define getc(s) getc_impl(s) no entra en un bucle infinito. La consecuencia práctica, más útil, es que puedes definir una macro con el mismo nombre que una función y usarla para envolverla, algo que la biblioteca estándar hace constantemente.

El patrón do while 0

El segundo grupo de macros no calcula un valor sino que ejecuta varias sentencias. Aquí el problema no es la precedencia sino la gramática: una macro de varias sentencias deja de ser una sentencia, y eso rompe todo contexto donde la gramática exige exactamente una.

#define REGISTRA(m) fputs(m, log); fflush(log);

if (fallo)
    REGISTRA("error");   /* fflush queda FUERA del if: se ejecuta siempre */
else
    sigue();             /* y ademas el else no compila */

Envolver el cuerpo en llaves resuelve el primer defecto y agrava el segundo: el bloque termina en llave, el punto y coma del punto de uso se convierte en una sentencia vacía y el else queda huérfano. La solución canónica es envolver el cuerpo en un bucle que se ejecuta una vez y nunca repite.

#define REGISTRA(m)          \
    do {                     \
        fputs((m), log);     \
        fflush(log);         \
    } while (0)

La construcción funciona porque do ... while solo está completa con su punto y coma final: la macro es sintácticamente una sentencia única y exige el punto y coma en el punto de uso, igual que una llamada a función. Con optimizaciones, el bucle desaparece por completo del código generado.

flowchart TB
A[macro con varias sentencias] --> B[cuerpo desnudo sin envoltorio]
A --> C[cuerpo entre llaves]
A --> D[patron do while cero]
B --> E[solo la primera sentencia entra en el if]
C --> F[el punto y coma del uso rompe el else]
D --> G[una sola sentencia que exige punto y coma]
E --> H[bug silencioso o error de compilacion]
F --> H
G --> I[se comporta como una llamada a funcion]
style H fill:#f38ba8,color:#11111b
style I fill:#a6e3a1,color:#11111b

Dos avisos sobre el idioma. Si la macro debe producir un valor, do ... while 0 no sirve: usa el operador coma o una expresión-sentencia. Y si tu compilador advierte de condición constante, la práctica habitual es silenciar esa advertencia concreta en la definición, no abandonar el patrón.

El criterio de decisión

Ante una macro con argumentos, la pregunta útil no es si funciona sino qué capacidad del preprocesador estás usando. Si la respuesta es ninguna, conviértela en función y recupera los tipos, los diagnósticos y el depurador.

Cuando el veredicto sea macro, aplica además tres convenciones de higiene: nómbrala en mayúsculas y con un prefijo de proyecto, porque el preprocesador no respeta espacios de nombres y una colisión reescribe código ajeno; documenta si evalúa algún argumento más de una vez; y usa #undef para retirarla en cuanto deje de hacer falta, sobre todo si vive en una cabecera pública.