Cake – C23 and Beyond (2023)

Original Article ↗ Hacker News Discussion ↗

Efforts to add Rust-style ownership and memory-safety checks to C via the Cake C23 front end are drawing both interest and skepticism. Proponents see value in compile‑time tracking of resource lifetimes (e.g., `malloc`/`free`, `fopen`/`fclose`) that can be layered onto existing code and compiled away for GCC/Clang, while critics question how well these annotations compose, how realistic it is to retrofit large libraries, and whether partial, opt‑in safety is worth the complexity. The conversation frequently contrasts this approach with alternatives like Rust, custom allocators, and mempools, raising the broader question of whether C should be incrementally hardened or replaced by inherently memory‑safe languages.

Ownership model in Cake

  • Cake adds _Owner, _View, etc. qualifiers and flow analysis to C23 to check resource lifetime (e.g., FILE * owner), focusing mainly on temporal safety (double free / use-after-free), not spatial bounds.
  • Ownership is part of the type system, not attributes, so returning an owner requires annotating the function return type; moves are tracked, and scopes with moved-from owners are not forced to “destroy”.
  • The system can treat non-pointer values (handles) as owners, enabling custom allocators and handle-based designs.

Retrofitting and composability

  • Strong concern that ownership “infects” APIs: once a function returns an owner, callers and their callers must adopt annotations.
  • Cake’s author notes similarity to adding const to a header: changes propagate broadly but stabilize over time.
  • Checks are disabled by default; including ownership.h and defining __OWNERSHIP_H__ turns them on. Macros allow compiling the same code with compilers that don’t support ownership.
  • Some patterns (e.g., linked lists) are shown to work cleanly; some functions in Cake’s own code have checks disabled when too awkward.

Safety guarantees and limitations

  • Current focus is temporal safety; out-of-bounds and general UB are not handled yet. Nullable references and lifetime-like analyses are planned but incomplete.
  • Static analysis is seen as valuable for rarely executed paths where runtime tools may never trigger.
  • There is debate whether “optional” safety (per-file defines, ability to silence checks) is compelling versus aiming for full memory safety.

Comparisons: Rust, RAII, mempools, isoheaps

  • Repeated comparisons to Rust’s ownership/borrow model: similarities in moves and drops, differences in dynamic drop semantics and explicit lifetimes.
  • Cake differs from C++ RAII: destruction is not unconditional; flow analysis decides whether destruction is required.
  • Some argue a good mempool or isoheaps can achieve similar safety; others counter that these don’t address UB broadly, and are not equivalent to static ownership checking.
  • Tension between “half measures” that still allow bugs versus strict models that force architectural change.

Tooling, integration, and ecosystem issues

  • Cake is a standalone C23 frontend that can output C99/C89, used both as compiler and static analyzer.
  • It can coexist with GCC/Clang by using empty ownership macros; there’s interest in plugin-like integration.
  • Practical success depends on annotating complex real-world libraries (e.g., OpenSSL), which is acknowledged as future work.