Acabo de lanzar CRUST. Se trata de un analizador estático de C que permite disponer en C de una gestión de memoria similar a la de RUST.

Y es que RUST está de moda, pues al ofrecer seguridad en el acceso a memoria dinámica pero sin necesidad de un runtime (como un recolector de basura) o de otras técnicas (como el conteo de referencias), permite exprimir al máximo el rendimiento. El problema es que RUST es un lenguaje nuevo, con su sintaxis propia (que, además, diverge de la de C u otros lenguajes bastante), y que, por tanto, tiene una curva de aprendizaje.

Por otro lado, existen casos en los que no se puede utilizar (todavía) RUST, como el de un microcontrolador PIC, Atmel…, pues hace falta un compilador específico. En otros microcontroladores, como los basados en ARM, es posible utilizarlo, pero sigue teniendo el problema de que no es un compilador oficial, y por tanto hay que hacer algún que otro malabar para integrarlo en la toolchain del fabricante.

Es aquí donde CRUST hace su aparición: como ya dije se trata de un analizador estático de C que permite disponer de (más o menos, claro) las mismas comprobaciones de seguridad que ofrece RUST para la gestión de memoria dinámica, de manera que es más difícil que un programa sufra referencias colgantes o dangling pointers, o pérdidas de memoria.

A la hora de diseñar CRUST tenía una cosa muy clara en mente: no podía crear un nuevo lenguaje parecido a C, sino que tenía que seguir siendo C puro, compilable con absolutamente cualquier compilador estándar. Eso eliminaba cualquier tipo de preprocesador del estilo de Metaobject o similares. También suponía rechazar cualquier tipo de conjunto de macros que pudiese alterar el código de la más mínima manera. Y por supuesto, el uso de bibliotecas estaba completamente descartado.

La solución consistió en crear una serie de calificadores específicos, similares en funcionamiento a los calificadores volatile o const ya disponibles en C, que permitan al analizador saber si un puntero concreto es gestionado o no-gestionado, así como otras propiedades importantes para el analizador. Estos calificadores comienzan todos con el prefijo __crust_ para evitar interferencias con nombres de variables o futuras adiciones al lenguaje C. La clave de estos calificadores es que no son necesarios en absoluto para compilar el código.

Por supuesto, ningún compilador aceptaría un código con dichos calificadores, y por eso es necesario incluir un fichero de cabecera (que se incluye con el analizador estático) que define dichos nuevos calificadores como espacios en blanco para el preprocesador de C. De esta manera, a la hora de compilar estos calificadores simplemente «desaparecen», y sólo son tenidos en cuenta cuando se utiliza el analizador. Este es un trozo de dicho fichero de cabecera, para que se entienda mejor:

#ifndef ENABLE_CRUST_TAGS

#ifndef __crust__
#define __crust__
#endif

#ifndef __crust_borrow__
#define __crust_borrow__
#endif

#ifndef __crust_recycle__
#define __crust_recycle__
#endif

#ifndef __crust_alias__
#define __crust_alias__
#endif

#ifndef __crust_no_0__
#define __crust_no_0__
#endif

...

Como se ve, se define cada posible calificador como una cadena vacía, lo que hace que el preprocesador se encargue de limpiar el código y dejarlo listo para el compilador, sin necesidad de modificar nada. Esto permite programar como de costumbre, simplemente etiquetando aquellos punteros que deben ser gestionados como un bloque CRUST, y compilando el código normalmente con el toolchain habitual, y sólo de vez en cuando pasar el analizador estático para comprobar si hemos cometido algún error al liberar o utilizar uno de estos bloques. Por supuesto, no es necesario escribir este fichero a mano, sino que se puede generar automáticamente simplemente llamando al analizador estático con el comando crust –headers, con lo que generará dicho fichero en el directorio actual.

La base de las reglas de gestión de memoria de CRUST (y, por extensión, de RUST) es que cada función es responsable de todos los bloques de memoria que genera o recibe. Así, si una función pide un bloque de memoria dinámica (por ejemplo con malloc), es su responsabilidad liberarlo o asegurarse que sea liberado. Esto puede ocurrir de tres maneras diferentes:

• Puede liberar el bloque directamente ella misma
• Puede llamar a otra función pasando dicho bloque como un parámetro, de manera que pase a ser responsabilidad de la nueva función garantizar que se libere dicho bloque
• Puede devolver el bloque a la función llamante, de manera que ésta recibe la responsabilidad de liberarlo

No hay mucho más. Por supuesto existen, a mayores, otros detalles que hacen que la cosa no sea tan sencilla, por lo que para una explicación más en profundidad recomiendo leer como es el modelo de memoria de RUST.

Un ejemplo sencillo de como trabaja CRUST se puede ver en este trozo de código:

// SIEMPRE añadimos crust.h al principio
// El fichero tiene que estar en el proyecto
#include "crust.h"
#include <unistd.h>

// Definimos una estructura como "gestionada"
// simplemente añadiendo __crust__ a su definición
// Utilizamos un typedef para ahorrarnos tener que poner
// __crust__ en todos los sitios donde se utiliza
typedef __crust__ struct {
	int member;
	int p1;
	int p2;
} *un_tipo_t;

// esta función crea un nuevo bloque "gestionado" y lo devuelve

un_tipo_t funcion1();

// esta función recibe un bloque "gestionado",
// pero no lo libera antes de salir

void funcion2(un_tipo_t __crust_borrow__ parametro);

// esta función recibe un puntero a un bloque "gestionado",
// y además lo libera antes de salir

uint32_t funcion3(un_tipo_t parametro);

void main() {

	un_tipo_t bloque = funcion1();

	funcion2(bloque);
	funcion3(bloque);
}

Aquí vemos varias cosas:

• Primero hacemos un typedef de un puntero a una estructura, y además incluimos el calificador __crust__. Esto significa que absolutamente cualquier variable de tipo un_tipo_t será gestionada, y por tanto sujeta a las reglas de CRUST.
• Luego tenemos tres definiciones de funciones que «hacen cosas» con tipos un_tipo_t.
• Finalmente, tenemos el bloque main. En él creamos un puntero de tipo un_tipo_t y le asignamos el bloque que nos devuelve funcion2.
• A continuación llamamos con dicho bloque a funcion3. Como dicho parámetro está marcado como __crust_borrow__, sabemos que dicha función nunca liberará dicho bloque, por lo que después de llamarla seguirá estando disponible y podemos seguir utilizándolo.
• Finalmente llamamos también con dicho bloque a funcion1. Como el parámetro de dicha función no está marcado como __crust_borrow__, sabemos a ciencia cierta que ese bloque que estamos pasando va a ser liberado dentro de ella, por lo que a partir de este punto no podemos volver a utilizarlo.
• Llegamos al final de la función, y como la variable bloque ya no apunta a nada (pues el bloque fue liberado al llamar a funcion3), no hay riesgo de que tengamos una fuga de memoria.

Este código no devolvería ningún error al pasar por el analizador estático CRUST precisamente porque cumple con precisión las reglas de gestión de memoria. Sin embargo, si hiciésemos un cambio tan sencillo como invertir el orden de las llamadas a funcion2() y funcion3(), obtendríamos un error:

ERROR: Argument 1 when calling function 'funcion2' at line 41 was freed at line 40
Total: 1 errors.

El motivo es que funcion2() libera el bloque de memoria que recibe, lo que significa que cuando llamamos después a funcion3() con él, CRUST sabe que ese bloque de memoria ya no existe, y nos avisa.

Algo similar ocurre si sólo llamamos a funcion2() (que sabemos que no libera el bloque) pero no llamamos a funcion3():

ERROR: Memory block 'bloque', initialized at line 38, is still in use at exit point in line 41
Total: 1 errors.

Aquí CRUST se da cuenta de que el bloque que hemos inicializado no ha sido liberado al llegar al final de la función. Si lo dejásemos así tendríamos una fuga de memoria, y por eso nos avisa diligentemente.

Por supuesto CRUST es lo suficientemente inteligente como para seguir las posibles ramas de ejecución del código. Probemos a modificar la función main() anterior y dejémosla así:

void main() {
	// "tmp" tiene un valor que desconocemos
	uint8_t tmp;

	un_tipo_t bloque = funcion1();

	if (tmp == 5) {
		return;
	}

	if (tmp == 8) {
		bloque = NULL;
	}

	if (tmp == 7) {
		bloque = funcion1();
	}

	if (tmp != 3) {
		funcion3(bloque);
	}
	funcion2(bloque);
}

Al pasar este código a través de CRUST obtenemos el siguiente resultado:

ERROR: Memory block 'bloque', initialized at line 42, is still in use at exit point in line 45
ERROR: Assignment to 'bloque' at line 49, which was already assigned at line 42
ERROR: Argument 1 when calling function 'funcion2' at line 59 was freed at line 57
ERROR: Memory block 'bloque', initialized at line 53, is still in use at exit point in line 60
ERROR: Assignment to 'bloque' at line 53, which was already assigned at line 42
ERROR: Memory block 'bloque', initialized at line 42, is still in use at exit point in line 60
Total: 6 errors.

Aquí nos está avisando de todos los errores que hemos cometido, que son:

• Si tmp vale 5 saldremos en el return de la primera comparación, con lo que el bloque que inicializamos en la línea 42 no se libera y tendremos una fuga de memoria.
• Si tmp vale 7 u 8 estaremos sobreescribiendo un puntero que apunta a un bloque válido en la línea 49, con lo que tendremos una fuga de memoria.
• Si tmp tiene un valor diferente de 3 liberaremos el bloque en la línea 49, con lo que al llamar a funcion2() tendremos una referencia colgante.
• Si tmp vale 3 todo parecerá funcionar correctamente hasta llegar al final de la función, donde nos encontraremos con que el bloque nunca se libera y tendremos una fuga de memoria. Este error nos aparece dos veces porque en una de las ramas de ejecución no liberamos el bloque recibido al principio (línea 42) y en la otra no liberamos el bloque obtenido cuando tmp vale 7.

Por supuesto, CRUST tiene algunas limitaciones. Por ejemplo, sólo recuerda si una variable es NULL (vale 0) o no (valor distinto de 0), pero no valores concretos. Esto significa que este código será analizado correctamente:

void main() {

	un_tipo_t bloque = funcion1();

	if (bloque != NULL) {
		funcion3(bloque);
		bloque = NULL;
	}

	if (bloque != NULL) {
		funcion2(bloque);
	}
}

CRUST sabe que bloque, tal cual es devuelto por funcion1() puede ser NULL o no NULL, pero cuando llega al primer if y analiza ambas posibles ramas, en la de dentro del if marca a bloque como no NULL, y en la de fuera como NULL. Cuando llama a funcion3() el bloque es liberado, y por eso no devuelve un error al asignar NULL a dicha variable. A partir de aquí ambas ramas de ejecución tienen NULL como valor de bloque, y CRUST es capaz de detectar correctamente que jamás se llamará a funcion2(), y por eso no devuelve ningún error.

Sin embargo, este bloque sí daría errores, pues CRUST no llega a tener un nivel de control tan fino de los valores de las variables:

void main() {

	uint8_t tmp;

	un_tipo_t bloque = funcion1();

	if (tmp == 3) {
		funcion3(bloque);
	}

	if (tmp != 3) {
		funcion2(bloque);
		funcion3(bloque);
	}
}

Este código devolvería estos errores:

ERROR: Argument 1 when calling function 'funcion2' at line 48 was freed at line 44
ERROR: Argument 1 when calling function 'funcion3' at line 49 was freed at line 44
ERROR: Memory block 'bloque', initialized at line 41, is still in use at exit point in line 51
Total: 3 errors.

Por supuesto, la forma correcta de hacer lo anterior sería esta:

void main() {

	uint8_t tmp;

	un_tipo_t bloque = funcion1();

	if (tmp == 3) {
		funcion3(bloque);
	} else {
		funcion2(bloque);
		funcion3(bloque);
	}
}

La cual sí sería analizada correctamente por CRUST.

Todo esto no son más que unas pinceladas, pues hay mucho más en CRUST (por ejemplo el prestamo de bloques, igual que en RUST), por lo que lo mejor es leerse la documentación completa, que viene en formato PDF.

Como de costumbre, se puede encontrar en mi página web y en el respositorio de CRUST en GitLab.