Cake – C23 y más allá (2023)
Los esfuerzos por añadir a C comprobaciones de ownership y seguridad de memoria al estilo de Rust mediante el frontend C23 Cake están generando tanto interés como escepticismo. Sus defensores ven valor en el seguimiento en tiempo de compilación de la vida útil de recursos (p. ej., `malloc`/`free`, `fopen`/`fclose`) que puede superponerse al código existente y compilarse fuera para GCC/Clang, mientras que los críticos cuestionan lo bien que estas anotaciones componen, lo realista que es adaptar bibliotecas grandes y si una seguridad parcial y optativa merece la complejidad. La conversación compara con frecuencia este enfoque con alternativas como Rust, asignadores personalizados y mempools, planteando la cuestión más amplia de si C debería endurecerse incrementalmente o ser reemplazado por lenguajes inherentemente seguros en memoria.
Modelo de propiedad en Cake
- Cake añade calificadores
_Owner,_View, etc. y análisis de flujo a C23 para comprobar la vida útil de los recursos (p. ej.,FILE * owner), centrándose principalmente en la seguridad temporal (double free / use-after-free), no en límites espaciales. - La propiedad forma parte del sistema de tipos, no de los atributos, así que devolver un owner requiere anotar el tipo de retorno de la función; los movimientos se rastrean, y los ámbitos con owners “movidos desde” no se ven forzados a “destruir”.
- El sistema puede tratar valores no puntero (handles) como owners, lo que permite asignadores personalizados y diseños basados en handles.
Adaptación y composabilidad
- Preocupa mucho que la propiedad “infecte” las APIs: una vez que una función devuelve un owner, quienes la llaman y quienes llaman a esas funciones deben adoptar anotaciones.
- El autor de Cake señala la similitud con añadir
consta un header: los cambios se propagan ampliamente, pero se estabilizan con el tiempo. - Las comprobaciones están desactivadas por defecto; incluir
ownership.hy definir__OWNERSHIP_H__las activa. Las macros permiten compilar el mismo código con compiladores que no soportan ownership. - Algunos patrones (p. ej., listas enlazadas) se muestran funcionando limpiamente; algunas funciones en el propio código de Cake tienen las comprobaciones desactivadas cuando resultan demasiado incómodas.
Garantías de seguridad y limitaciones
- La atención actual está en la seguridad temporal; los desbordamientos de límites y el UB general todavía no se manejan. Se planean referencias anulables y análisis similares al de vida útil, pero están incompletos.
- El análisis estático se considera valioso para rutas que se ejecutan rara vez, donde las herramientas en tiempo de ejecución quizá nunca se activen.
- Hay debate sobre si una seguridad “opcional” (defines por archivo, posibilidad de silenciar comprobaciones) es convincente frente a buscar seguridad de memoria completa.
Comparaciones: Rust, RAII, mempools, isoheaps
- Comparaciones repetidas con el modelo de ownership/borrow de Rust: similitudes en movimientos y drops, diferencias en la semántica dinámica de drop y en los lifetimes explícitos.
- Cake difiere del RAII de C++: la destrucción no es incondicional; el análisis de flujo decide si la destrucción es necesaria.
- Algunos argumentan que un buen mempool o los isoheaps pueden lograr una seguridad similar; otros responden que eso no aborda el UB de forma amplia y no es equivalente a la comprobación estática de ownership.
- Tensión entre “medidas a medias” que aún permiten errores y modelos estrictos que fuerzan cambios arquitectónicos.
Herramientas, integración y cuestiones del ecosistema
- Cake es un frontend C23 independiente que puede generar C99/C89, y se usa tanto como compilador como analizador estático.
- Puede coexistir con GCC/Clang usando macros de ownership vacías; hay interés en una integración tipo plugin.
- El éxito práctico depende de anotar bibliotecas reales y complejas (p. ej., OpenSSL), algo que se reconoce como trabajo futuro.