Disciplina de propiedad: quién libera qué

C no tiene destructores, no tiene ámbitos que liberen, no tiene un verificador de préstamos y no tiene forma de distinguir en el tipo un puntero que posee de uno que solo mira. Todo eso significa que la propiedad de la memoria existe igualmente —cada bloque tiene un dueño y una obligación de destrucción— pero vive fuera del programa, en la cabeza de quien lo escribió. La disciplina de propiedad consiste en devolver esa información al código por los únicos canales disponibles: el nombre de las funciones, la forma de las firmas, la documentación junto al prototipo y un puñado de patrones que hacen que la respuesta correcta sea también la más cómoda de escribir.

La regla única y sus dos operaciones

Toda la disciplina se reduce a un enunciado: cada bloque reservado tiene, en todo instante, exactamente un dueño, y el dueño es quien está obligado a destruirlo exactamente una vez. Todos los defectos clásicos son violaciones de esa frase. Cero dueños producen una fuga. Dos dueños producen una doble liberación. Un dueño que destruye mientras otro sigue mirando produce un uso tras liberación.

Sobre esa regla solo hay dos operaciones posibles cuando un puntero cruza la frontera de una función. La transferencia mueve la obligación: quien recibe el puntero queda obligado a destruirlo, y quien lo entregó deja de poder usarlo. El préstamo no mueve nada: quien recibe puede leer o escribir durante la llamada, pero no destruye ni guarda la dirección más allá de la vida del objeto prestado.

Como el compilador no verifica cuál de las dos está ocurriendo, la única defensa es que sea evidente al leer la llamada. Una función que devuelve un puntero al montón casi siempre transfiere; una función que recibe un const char * casi nunca. Las excepciones a esas expectativas son precisamente donde aparecen los errores, así que deben nombrarse y documentarse de forma agresiva.

flowchart LR
A[Constructor reserva y devuelve el objeto] --> B[El llamante es el dueno]
B --> C[Prestamo a una funcion que solo consulta]
C --> B
B --> D[Transferencia a un contenedor que asume la obligacion]
D --> E[El contenedor destruye sus elementos]
B --> F[Destructor libera y la obligacion se extingue]
style B fill:#89b4fa,color:#11111b
style F fill:#a6e3a1,color:#11111b

Convenciones que hacen visible al dueño

Un nombre bien elegido comunica la propiedad sin necesidad de abrir la implementación, y esa es toda su función. Las convenciones que se han impuesto en las bases de código serias de C son pocas y conviene adoptarlas tal cual, porque su valor está en ser compartidas.

El segundo canal es la cabecera, y es el más importante porque es lo único que lee quien usa tu módulo. La documentación de propiedad no es un comentario decorativo: es la parte del contrato que el lenguaje no puede escribir, y su ausencia obliga a leer la implementación para poder llamar a la función.

// buffer.h

typedef struct Buffer Buffer;

// Crea un buffer vacio. Devuelve nullptr si falla.
// PROPIEDAD: el llamante recibe la propiedad y debe llamar a
// buffer_destruir exactamente una vez.
Buffer *buffer_crear(size_t capacidad_inicial);

// Libera el buffer y todo lo que contiene. Acepta nullptr sin efecto.
void buffer_destruir(Buffer *b);

// PROPIEDAD: prestamo. La cadena devuelta pertenece al buffer y deja
// de ser valida tras cualquier operacion que lo modifique o destruya.
const char *buffer_texto(const Buffer *b);

// PROPIEDAD: transferencia. El buffer adopta la cadena y la liberara
// en buffer_destruir. Tras la llamada, no uses tu puntero.
bool buffer_adoptar(Buffer *b, char *cadena_del_monton);

Ese bloque de cuatro prototipos contiene más información sobre la gestión de memoria del módulo que cualquier cantidad de código bien escrito sin él. Conviene además que el tipo sea opaco, declarado en la cabecera y definido solo en el fichero de implementación: así nadie puede reservar un objeto en su pila, nadie puede liberar un campo interno y las dos únicas puertas de entrada son el constructor y el destructor.

Constructor y destructor en C

El patrón tiene una forma canónica que resuelve simultáneamente la reserva, la inicialización y el fallo a mitad de camino. El constructor reserva la estructura, inicializa cada recurso en orden y, si alguno falla, deshace en orden inverso lo ya hecho mediante etiquetas de limpieza escalonadas.

struct Buffer {
    char   *datos;
    size_t  longitud;
    size_t  capacidad;
    FILE   *registro;
};

Buffer *buffer_crear(size_t capacidad_inicial) {
    Buffer *b = calloc(1, sizeof *b);        // cero: todo campo queda nulo
    if (!b) return nullptr;

    b->datos = malloc(capacidad_inicial);
    if (!b->datos) goto fallo_datos;

    b->registro = fopen("buffer.log", "w");
    if (!b->registro) goto fallo_registro;

    b->capacidad = capacidad_inicial;
    return b;

fallo_registro:
    free(b->datos);
fallo_datos:
    free(b);
    return nullptr;
}

El uso de calloc no es un capricho: al dejar todos los campos a cero, cualquier destrucción parcial encuentra punteros nulos en los recursos que aún no se habían adquirido, y liberar un puntero nulo es una operación válida y sin efecto. Esa propiedad de free es la que sostiene todo el patrón, y por eso el destructor debe imitarla.

void buffer_destruir(Buffer *b) {
    if (!b) return;                  // tolerante al nulo, como free
    if (b->registro) fclose(b->registro);
    free(b->datos);                  // libera lo que posee, en orden inverso
    free(b);                         // y por ultimo la estructura
}

Tres propiedades hacen que este destructor sea correcto y que sus variantes descuidadas no lo sean. Acepta el puntero nulo sin efecto, lo que elimina una comprobación en cada punto de llamada. Libera en orden inverso a la adquisición, lo que importa en cuanto un recurso depende de otro. Y libera todo lo que el objeto poseía, de forma recursiva: si el buffer contuviera un arreglo de objetos propios, el destructor recorrería ese arreglo destruyendo cada elemento antes de liberar el arreglo.

Propiedad compartida y sus límites

A veces la respuesta honesta a la pregunta de quién es el dueño es que hay varios candidatos y ninguno sabe cuál terminará último. Es el caso de un objeto grande referenciado por varias estructuras con vidas independientes. La solución clásica es el recuento de referencias: el objeto guarda cuántos interesados tiene, cada nuevo interesado incrementa, cada uno que termina decrementa, y el que lleva la cuenta a cero ejecuta la destrucción.

typedef struct { atomic_int refs; char *datos; } Recurso;

Recurso *recurso_retener(Recurso *r) {
    atomic_fetch_add_explicit(&r->refs, 1, memory_order_relaxed);
    return r;
}

void recurso_soltar(Recurso *r) {
    if (!r) return;
    if (atomic_fetch_sub_explicit(&r->refs, 1, memory_order_acq_rel) == 1) {
        free(r->datos);
        free(r);
    }
}

El recuento no es gratis y sus tres costes deben conocerse antes de adoptarlo. Si el objeto se comparte entre hilos, el contador debe ser atómico, y una operación atómica de lectura y modificación cuesta bastante más que un incremento normal, además de invalidar la línea de caché en el resto de núcleos. Convierte además la propiedad en una decisión de tiempo de ejecución: ya no puedes saber leyendo el código cuándo se destruye el objeto. Y falla de forma silenciosa ante los ciclos, porque dos objetos que se referencian mutuamente mantienen sus contadores por encima de cero para siempre, aunque nadie más los alcance. Ese es exactamente el motivo por el que los lenguajes que usan recuento como mecanismo principal ofrecen referencias débiles.