Portabilidad: estándar, POSIX y extensiones

Portable no significa que funcione en tu máquina y en la del compañero. Significa que sabes exactamente qué contrato asumes, que ese contrato está escrito en el código y no en tu cabeza, y que algo automático lo comprueba. La mayoría del código que se llama portable solo ha sido probado en un sitio; la diferencia entre eso y la portabilidad real son unas pocas macros y una forma distinta de razonar.

Tres círculos concéntricos

Cuando escribes #include <stdio.h> no obtienes “lo que hay en la cabecera”: obtienes el subconjunto que corresponde al contrato que declaraste. Hay tres círculos.

El interior es ISO C, el estándar del lenguaje, hoy C23. Define el lenguaje, unas treinta cabeceras y nada más. No sabe qué es un archivo del sistema, un proceso, un socket ni un permiso. fopen existe; open no. Es el único círculo que se cumple en un microcontrolador, en un kernel o en una implementación freestanding.

El intermedio es POSIX, que estandariza el sistema operativo: descriptores de archivo, procesos, señales, hilos, sockets, permisos, terminales. Lo cumplen Linux, los BSD y macOS con matices; Windows nativo no. Ahí viven open, fork, pthread_create, dup2 y getopt.

El exterior son las extensiones de cada implementación: lo que glibc o el propio compilador añaden por su cuenta y nadie más garantiza. asprintf, memmem, las funciones anidadas o los atributos de GCC.

flowchart TD
A[Extensiones de la implementacion] --> B[POSIX y XSI]
B --> C[ISO C 23]
C --> D[Freestanding: solo lenguaje y cabeceras minimas]
style C fill:#a6e3a1,color:#11111b
style A fill:#f38ba8,color:#11111b

La frontera se mueve. C23 absorbió de POSIX funciones que llevaban décadas siendo extensiones: strdup, strndup, memccpy, gmtime_r y localtime_r son hoy ISO C. Saber en qué círculo vive cada función que usas es la mitad del trabajo de portabilidad.

Las macros de test de características

El mecanismo que selecciona el círculo son las macros de test de características. No son opcionales ni decorativas: las cabeceras de glibc incluyen features.h, leen esas macros y declaran u ocultan prototipos en consecuencia.

Dos reglas que se incumplen a diario. La primera: la definición debe preceder a toda inclusión, sin excepción. Si una cabecera entra antes, sus guardas de inclusión impiden que reevalúe nada y la macro no tendrá efecto, sin un solo aviso.

#define _POSIX_C_SOURCE 200809L   // primero, antes que cualquier #include
#include <stdio.h>
#include <unistd.h>

La segunda: la bandera del compilador también decide. Con -std=c23 pides ISO estricto y gcc deja de predefinir el conjunto por defecto, así que funciones POSIX que compilaban ayer desaparecen. Con -std=gnu23 el compilador predefine _DEFAULT_SOURCE y todo vuelve a estar visible. Ese es el motivo exacto de errores como una declaración implícita de fileno o de popen en un proyecto que solo cambió de bandera.

gcc -std=c23  -Wall prog.c    # ISO estricto: sin POSIX salvo que lo pidas
gcc -std=gnu23 -Wall prog.c   # con extensiones y POSIX visibles por defecto

La recomendación profesional es la incómoda: usa -std=c23 y declara explícitamente el nivel de POSIX que necesitas. Cuesta una línea y convierte una dependencia invisible en un requisito escrito.

Lo que el estándar no promete

Portabilidad no es solo disponibilidad de funciones; es también no depender de lo que el estándar dejó abierto. Hay tres categorías y confundirlas es caro.

Definido por la implementación: el estándar exige una elección y que se documente. Si char es con signo o sin signo, cuántos bits tiene un int, cómo se representa un puntero convertido a entero. Depender de ello es legítimo si lo declaras.

No especificado: hay varias opciones válidas y nadie tiene que decirte cuál. El orden de evaluación de los argumentos de una llamada, o el orden en que se disponen ciertos objetos en memoria.

Indefinido: no hay contrato de ninguna clase y el compilador puede asumir que nunca ocurre. Desbordar un entero con signo, leer memoria liberada, violar el aliasing estricto. Aquí no hay portabilidad posible porque ni siquiera hay programa.

El repertorio de trampas es conocido y se evita con disciplina. El tamaño de los enteros cambia entre modelos: en Linux de 64 bits long mide 8 bytes, en Windows de 64 bits mide 4. La solución es stdint.h con tipos de anchura fija y inttypes.h para imprimirlos.

#include <inttypes.h>
#include <limits.h>
#include <stdint.h>
#include <stdio.h>

static_assert(CHAR_BIT == 8, "esta implementacion asume octetos");

int main(void) {
    uint64_t n = 1;
    printf("%" PRIu64 "\n", n);   // nunca %lu: no es portable
    size_t s = sizeof n;
    printf("%zu\n", s);           // %zu es el especificador correcto
}

Nótese que %zu para size_t y las macros PRIu64 no son manías estilísticas: pasar el especificador equivocado a una función variádica es comportamiento indefinido, no un aviso cosmético. C23 mejora el terreno al exigir representación en complemento a dos, lo que elimina de golpe varias ambigüedades históricas sobre enteros con signo.

Las dos trampas restantes son de representación en memoria. El orden de bytes no está especificado, así que volcar una estructura a un archivo o a un socket y leerla en otra máquina produce números distintos; la solución no es detectar la arquitectura, sino serializar byte a byte con desplazamientos, que es correcto en cualquier orden. Y el alineamiento: leer un entero de cuatro bytes desde una dirección no alineada es indefinido aunque en x86 funcione, y en otras arquitecturas provoca una excepción o una lectura silenciosamente lenta. La forma portable de reinterpretar bytes es memcpy, que el compilador reduce a una instrucción cuando puede.

uint32_t leer_be32(const unsigned char *p) {
    return (uint32_t)p[0] << 24 | (uint32_t)p[1] << 16
         | (uint32_t)p[2] << 8  | (uint32_t)p[3];
}

Escribir código que de verdad viaja

La estrategia que funciona no es sembrar el código de condicionales de plataforma, sino aislar. Define una interfaz propia en términos de tu dominio, y que cada plataforma tenga su implementación en un archivo distinto, elegido por el sistema de compilación. Así el noventa por ciento de tu código no sabe en qué sistema corre y el diez por ciento restante está concentrado, aislado y es fácil de auditar.

Cuando necesites condicionales, detecta la característica, no el sistema. Preguntar por el sistema operativo es frágil porque la relación entre sistema y funcionalidad cambia; preguntar por la función es exacto. C23 aporta una herramienta directa para esto:

#if defined(__has_include)
#  if __has_include(<sys/random.h>)
#    include <sys/random.h>
#    define TENGO_GETRANDOM 1
#  endif
#endif

Para lo que no se resuelve con cabeceras están las comprobaciones del sistema de compilación, que ejecutan una compilación de prueba y definen una macro según el resultado. En Meson eso es cc.has_function y cc.has_header; el equivalente clásico es el configure de Autotools. La ventaja es que la respuesta la da el compilador de destino, no tu memoria.

El resto es higiene verificable: compila con gcc y con clang, porque cada uno detecta cosas distintas; activa -Wall -Wextra -Wpedantic para que el compilador te avise cuando uses una extensión sin darte cuenta; ejecuta las pruebas en más de una libc y en más de una arquitectura, si es posible una de orden de bytes distinto; y escribe con static_assert las suposiciones que no puedas evitar, para que fallen al compilar y no en producción.