Cake – C23 e Além (2023)

Artigo original ↗ Discussão no Hacker News ↗

Esforços para adicionar verificações de ownership e segurança de memória ao estilo Rust ao C por meio do frontend C23 Cake estão despertando tanto interesse quanto ceticismo. Defensores veem valor em rastrear em tempo de compilação o tempo de vida de recursos (por exemplo, `malloc`/`free`, `fopen`/`fclose`) de forma que possa ser encaixado em código existente e removido na compilação para GCC/Clang, enquanto críticos questionam o quanto essas anotações compõem bem, quão realista é retrofitar bibliotecas grandes e se uma segurança parcial, opcional, vale a complexidade. A conversa frequentemente contrapõe essa abordagem a alternativas como Rust, allocators personalizados e mempools, levantando a questão mais ampla de se o C deve ser endurecido incrementalmente ou substituído por linguagens inerentemente seguras em relação à memória.

Modelo de propriedade em Cake

  • Cake adiciona qualificadores _Owner, _View, etc. e análise de fluxo a C23 para verificar o tempo de vida de recursos (por exemplo, FILE * owner), focando principalmente em segurança temporal (double free / use-after-free), não em limites espaciais.
  • Ownership faz parte do sistema de tipos, não de atributos, então retornar um owner exige anotar o tipo de retorno da função; moves são rastreados, e escopos com owners movidos não são forçados a “destroy”.
  • O sistema pode tratar valores não ponteiro (handles) como owners, permitindo allocators personalizados e designs baseados em handles.

Retrofit e composabilidade

  • Há forte preocupação de que ownership “infecte” as APIs: uma vez que uma função retorna um owner, chamadores e os chamadores deles precisam adotar anotações.
  • O autor de Cake observa semelhança com adicionar const a um header: as mudanças se propagam amplamente, mas se estabilizam com o tempo.
  • As verificações são desativadas por padrão; incluir ownership.h e definir __OWNERSHIP_H__ as ativa. Macros permitem compilar o mesmo código com compiladores que não suportam ownership.
  • Alguns padrões (por exemplo, listas encadeadas) são mostrados funcionando de forma limpa; algumas funções no próprio código de Cake têm verificações desativadas quando ficam incômodas demais.

Garantias de segurança e limitações

  • O foco atual é segurança temporal; out-of-bounds e UB geral ainda não são tratados. Referências anuláveis e análises do tipo lifetime estão planejadas, mas incompletas.
  • Análise estática é vista como valiosa para caminhos executados raramente, onde ferramentas em tempo de execução talvez nunca acionem.
  • Há debate sobre se segurança “opcional” (defines por arquivo, capacidade de silenciar verificações) é realmente atraente, versus buscar segurança de memória completa.

Comparações: Rust, RAII, mempools, isoheaps

  • Comparações repetidas com o modelo de ownership/borrow do Rust: semelhanças em moves e drops, diferenças na semântica dinâmica de drop e em lifetimes explícitos.
  • Cake difere de RAII em C++: a destruição não é incondicional; a análise de fluxo decide se a destruição é necessária.
  • Alguns argumentam que um bom mempool ou isoheaps pode alcançar segurança semelhante; outros respondem que isso não trata UB de forma ampla e não é equivalente à verificação estática de ownership.
  • Há tensão entre “meias-medidas” que ainda permitem bugs e modelos estritos que forçam mudança arquitetural.

Ferramentas, integração e questões de ecossistema

  • Cake é um frontend C23 independente que pode gerar C99/C89, usado tanto como compilador quanto como analisador estático.
  • Ele pode coexistir com GCC/Clang usando macros vazias de ownership; há interesse em integração no estilo plugin.
  • O sucesso prático depende de anotar bibliotecas reais complexas (por exemplo, OpenSSL), o que é reconhecido como trabalho futuro.