Modelar el dominio con tipos

C tiene un sistema de tipos débil por diseño: casi todo se convierte en casi todo, los alias no distinguen nada y un puntero es un puntero venga de donde venga. Pero débil no significa inútil. Con tres construcciones —la struct incompleta, la struct de un solo campo y el índice con generación— puedes fabricar fronteras que el compilador sí vigila, y concentrarlas exactamente donde los errores cuestan caro. No obtendrás las garantías de Rust; obtendrás bastantes más de las que el lenguaje parece ofrecer.

Tipos opacos: la frontera que el compilador vigila

Un tipo opaco es una struct declarada en el header sin cuerpo. El compilador la trata como tipo incompleto: sabe que existe, ignora su tamaño y rechaza cualquier intento de tocar sus campos o de declarar una variable de ese tipo por valor.

/* buffer.h */
typedef struct Buffer Buffer;                    /* incompleto a proposito */

[[nodiscard]] Buffer *buffer_crear(size_t capacidad);
void                  buffer_destruir(Buffer *b);
[[nodiscard]] bool    buffer_escribir(Buffer *b, const void *datos, size_t n);
size_t                buffer_longitud(const Buffer *b);

Esa incompletitud es el contrato entero. El usuario no puede leer un campo aunque quiera, no puede depender del tamaño y no se romperá cuando añadas, reordenes o elimines miembros; la única superficie que existe es la que has declarado. A cambio pagas dos precios reales: la struct solo puede vivir tras un puntero —normalmente en el heap—, y cada acceso pasa por una llamada que el compilador no puede insertar si la definición vive en otra unidad de traducción, salvo que actives optimización en tiempo de enlazado.

El atributo [[nodiscard]], estandarizado en C23, cierra la fuga más frecuente de este diseño: ignorar el valor devuelto. Aplicado al constructor y a toda función que informe de un fallo, convierte en advertencia lo que antes era un descuido invisible.

Cuando el heap no es una opción —código embebido, arranque, rutas sin asignación dinámica— existe la variante opaca con tamaño: el header expone un búfer de bytes con tamaño y alineación fijados, y la implementación coloca dentro la struct real.

/* mutex.h: opaco pero instanciable por valor */
typedef struct { alignas(void *) unsigned char _almacen[48]; } Mutex;

Es la técnica de pthread_mutex_t y de los tipos de threads.h. Conserva la opacidad para el usuario pero congela el tamaño en el ABI: ampliarlo rompe binarios ya compilados, así que se sobredimensiona desde el principio.

Envoltorios de un solo campo

typedef no distingue Metros de Segundos porque no crea tipos. Una struct sí:

typedef struct { int32_t v; } Metros;
typedef struct { int32_t v; } Pies;

static inline Metros metros(int32_t x) { return (Metros){ .v = x }; }
static inline Metros metros_sumar(Metros a, Metros b) { return metros(a.v + b.v); }

Metros d = metros(100);
Pies   p = { .v = 30 };
d = p;                    /* ERROR: tipos incompatibles. Justo lo que queriamos */

Dos structs con miembros idénticos son tipos distintos e incompatibles en C, y ninguna conversión implícita las une. Ese es todo el truco, y es suficiente para eliminar de raíz una familia entera de errores: mezclar metros con pies, milisegundos con segundos, identificadores de usuario con identificadores de pedido, bytes con elementos.

El coste en ejecución es esencialmente nulo. En los ABI habituales de 64 bits, una struct de un solo entero se pasa en registro igual que el entero desnudo y el acceso .v se compila a nada. El coste real es de ergonomía: pierdes los operadores aritméticos y tienes que declarar metros_sumar, metros_comparar y las que uses. Esa fricción es, en parte, la funcionalidad: si sumar dos magnitudes exige escribir una función, sumar dos magnitudes incompatibles se vuelve un acto deliberado en vez de un descuido.

Handles con generación

Hay un tercer instrumento, menos conocido y muy potente en sistemas con muchos objetos de vida corta: sustituir el puntero por un handle, un par de enteros que identifica una ranura y la encarnación concreta que la ocupa.

typedef struct { uint32_t indice; uint32_t generacion; } IdEntidad;

typedef struct {
    Entidad   ranuras[MAX];
    uint32_t  generacion[MAX];   /* se incrementa en cada liberacion */
    bool      viva[MAX];
} Pool;

Entidad *pool_resolver(Pool *p, IdEntidad id) {
    if (id.indice >= MAX) return nullptr;
    if (!p->viva[id.indice]) return nullptr;
    if (p->generacion[id.indice] != id.generacion) return nullptr;  /* handle rancio */
    return &p->ranuras[id.indice];
}

Lo que compra este diseño es notable. Un handle a un objeto ya liberado no es un puntero colgante que produce comportamiento indefinido: es un handle cuya generación no coincide, y resolverlo devuelve nulo de forma determinista y detectable. El pool puede crecer y reubicar su memoria sin invalidar nada, porque nadie guarda direcciones. Y el handle es un valor de 64 bits sin punteros dentro, lo que lo hace trivialmente serializable, comparable y transmisible entre procesos.

El precio es una indirección por acceso y la disciplina de no filtrar jamás el puntero resuelto más allá de la operación en curso. Es el patrón dominante en motores de juego, en sistemas de entidades y en asignadores con arenas, y merece considerarse siempre que la vida de los objetos sea difícil de razonar.

flowchart TB
A[Handle con indice y generacion] --> B{Indice dentro de rango}
B -->|No| X[Devuelve nulo]
B -->|Si| C{Ranura viva}
C -->|No| X
C -->|Si| D{Generacion coincide}
D -->|No| X
D -->|Si| E[Puntero valido durante esta operacion]

Lo que C no puede expresar

Conviene ser honesto sobre el techo. C carece de tipos suma nativos: una unión etiquetada hay que construirla a mano con un enum de tipo fijo, una union y la disciplina de no leer nunca el miembro equivocado, y el lenguaje no verifica esa correspondencia —solo el switch sin default con -Wall te ayuda, y solo con la etiqueta.

/* La aproximacion de C al tipo suma: union etiquetada */
typedef struct {
    enum : uint8_t { R_VALOR, R_ERROR } etiqueta;   /* enum anonimo con tipo fijo */
    union {
        Buffer *valor;    /* legible solo si etiqueta vale R_VALOR */
        int     codigo;   /* legible solo si etiqueta vale R_ERROR */
    };
} Resultado;

static inline Resultado resultado_ok(Buffer *b) {
    return (Resultado){ .etiqueta = R_VALOR, .valor = b };
}
static inline Resultado resultado_error(int c) {
    return (Resultado){ .etiqueta = R_ERROR, .codigo = c };
}

Los dos constructores son la mitad que sí puedes hacer cumplir: si nadie construye un Resultado con llaves, la etiqueta y el miembro activo nunca se desincronizan. La otra mitad —que quien lo recibe consulte la etiqueta antes de leer— sigue siendo una regla social, y ninguna versión de C la convierte en un error de compilación.

Tampoco hay un tipo de puntero no nulo, así que la nulabilidad se documenta pero no se comprueba. No hay propiedad ni tiempos de vida en el sistema de tipos: quién libera qué es un comentario, no un teorema. No hay destructores, de modo que la liberación automática al salir de ámbito solo llega mediante extensiones como el atributo cleanup de GCC y Clang. Y no hay exhaustividad garantizada: la que te da -Wswitch es una advertencia que cualquiera puede silenciar.

De ahí sale el criterio práctico. Estas tres herramientas cuestan escritura, y aplicarlas a todo produce código ceremonioso que nadie mantiene. Gástalas donde el error es caro y probable: en la frontera del módulo, donde entran datos que no controlas; en las magnitudes que se confunden entre sí; y en los objetos cuya vida no puedes razonar de un vistazo. Dentro de una función de treinta líneas, un int sigue siendo un int.