Libc do Zig

• A linguagem Zig está mudando de direção para implementar diretamente a funcionalidade de libc na biblioteca padrão do Zig, removendo gradualmente o código-fonte C existente
• Até agora, cerca de 250 arquivos-fonte em C foram removidos, e 2032 ainda permanecem
• Essa transição traz efeitos como melhora na velocidade de compilação, redução do tamanho da instalação e diminuição do tamanho do binário em linkagem estática
• Com uma melhoria recente, a libc do Zig é otimizada junto com outros códigos dentro da Zig Compilation Unit (ZCU), em vez de ser um arquivo estático separado, permitindo eliminação de código duplicado e otimizações em nível de LTO
• À medida que o Zig passa a atuar como seu próprio fornecedor de libc estática, em caso de problemas relacionados é necessário enviar relatórios de bug diretamente para o projeto Zig

---

Visão geral do projeto libc do Zig

• Vários contribuidores estão participando do subprojeto zig libc, substituindo a implementação existente de libc baseada em C por wrappers da biblioteca padrão do Zig
  • O objetivo é remover código C duplicado e fornecer funções como memcpy, atan2 etc. por meio de mapeamentos simples, ou no formato de wrapping de funções comuns como strnlen
  • Como exemplo, a função strnlen é implementada usando std.mem.findScalar do Zig
• Até agora, cerca de 250 arquivos-fonte em C foram removidos, e 2032 ainda permanecem

Melhorias de desempenho e estruturais

• À medida que cada função é convertida para Zig, há redução da dependência de projetos externos e da linguagem C
  • Isso resulta em melhora na velocidade de compilação, simplificação e redução do tamanho da instalação e redução do tamanho dos binários de aplicações de usuário com linkagem estática
• Uma mudança recente fez com que a libc do Zig fosse compilada junto com outros códigos Zig dentro da Zig Compilation Unit (ZCU)
  • Em vez de ser vinculada como um arquivo estático separado, ela aproveita a estrutura integrada do compilador e do linker
  • Com isso, tornam-se possíveis a eliminação de código duplicado e a otimização entre funções
  • Isso é semelhante à otimização em tempo de link (LTO), mas é feito na fase de frontend, e não na etapa do linker

Possibilidades de expansão futura

• Quando combinado com as recentes mudanças em std.Io, pode surgir a possibilidade de o usuário controlar o comportamento de I/O da libc
  • Ex.: integrar chamadas read e write ao event loop do io_uring
  • Também pode ser possível aplicar detecção de vazamento de recursos a código C de terceiros
  • No entanto, por enquanto isso ainda está na fase de ideias não testadas

Testes e garantia de qualidade

• O projeto libc-test de Szabolcs Nagy tem ajudado bastante a evitar regressões em funções matemáticas
  • Esse conjunto de testes é usado para verificar a precisão da libc do Zig

Orientação para usuários

• O Zig está em transição para fornecer por conta própria a funcionalidade de musl, mingw-w64 e wasi-libc
  • Em caso de problemas relacionados, é necessário enviar relatórios de bug diretamente para o projeto Zig
  • Isso serve para evitar que issues incorretas sejam encaminhadas aos mantenedores dos projetos libc independentes existentes

Encerramento

• A última frase do texto termina com “Abolish ICE” (sem explicação adicional)

[GN⁺]

Comentários do Hacker News

• 250 arquivos C foram removidos, e agora restam 2032
  Acompanhar o Zig substituindo a libc de dentro para fora é um projeto bem empolgante no longo prazo

  • Sempre admirei esse aspecto do Zig
    Muitas linguagens dizem substituir C, mas o Zig foi praticamente a única que integrou naturalmente a ABI de C e o sistema de build
    O recurso translate-c também funciona surpreendentemente bem
    Acho que foi uma escolha mais inteligente não tentar manter 99% de compatibilidade como o C++, e sim preservar a simplicidade do C evitando as armadilhas da linguagem

• Fico me perguntando se isso significa que, no longo prazo, o Zig não vai rodar no OpenBSD
  O OpenBSD bloqueia syscalls diretas e força chamadas apenas via libc
  Veja este tópico

  • Isso vale apenas para a libc estática
    Se usar a opção -dynamic -lc, as funções libc do sistema-alvo serão fornecidas
    Há sistemas, como o macOS, que suportam apenas libc dinâmica, e pelo que sei o OpenBSD também suporta libc estática
  • A resposta relacionada pode ser vista aqui

• É uma mudança muito interessante na forma como o projeto Zig faz linkagem com bibliotecas C
  Mas, ao compilar cruzado com Zig um programa C para Windows usando MinGW, fico curioso se ainda é possível linkar estaticamente a libc do MinGW

  • Nesse caso, nada muda
    Ao especificar -target x86_64-windows-gnu -lc, algumas funções da libc são fornecidas pelo Zig, e outras pelo mingw-w64 embutido
    O Zig fornece tudo sem necessidade de uma instalação separada do mingw-w64
    Se quiser, também é possível apontar manualmente para uma libc externa com --libc libc.txt

• É uma ideia legal, mas me preocupo se será preciso continuar acompanhando as vulnerabilidades CVE do glibc ou do musl no código portado

  • Isso já está sendo feito também na biblioteca padrão
    Em caminhos de código compartilhados, como matemática, isso pode até reduzir bugs em potencial

• Houve a explicação de que isso é “parecido com ativar LTO além da fronteira da libc, mas feito corretamente no frontend em vez de no linker”
  Fico curioso por que na etapa do linker já seria tarde demais, e se o Zig consegue fazer mais otimizações do que um linker no nível de LLVM IR

  • No frontend, é possível fazer inlining e eliminação de código morto
    Em bibliotecas estáticas já otimizadas, esse tipo de otimização é difícil no momento da linkagem

• Combinado com as mudanças recentes em std.Io, é interessante que o usuário possa controlar diretamente o comportamento de I/O da libc
  Por exemplo, fazendo com que todas as chamadas de read/write participem do loop de eventos do io_uring
  Pessoalmente tenho mais interesse no lado do kqueue, mas essa citação parece se aplicar ali também

• A libc tem várias partes assustadoras, mas este é realmente um projeto interessante

  • Claro, ela também tem funções úteis
    Por exemplo, coisas como "memfrob" ou "strfry" — brincadeira, mas isso só existe no glibc :)

• Fico curioso se existe algo assim no Rust
  Não quero iniciar uma discussão Zig vs Rust, só queria criar um ambiente mais independente também em projetos Rust

  • Existem algumas implementações de libc em Rust
    • c-ward: implementação de libc escrita em Rust
    • relibc: voltada para o Redox OS, mas também funciona no Linux
    • rustix: faz bindings seguros para a API POSIX sem usar C

• Fico curioso se alguém sabe quando o Zig vai chegar à versão 1.0
  Tenho bastante interesse na linguagem, mas ainda há muitas mudanças, então hesito em usá-la em projetos importantes

  • Ninguém sabe ao certo
    Ainda assim, grandes projetos de produção como Bun, Ghostty e Tigerbeetle estão acompanhando bem
    Como a semântica do Zig é simples, mesmo ao atualizar de versão normalmente basta atualizar o compilador e fazer algumas correções mecânicas
    O que me impede é só a disposição dos colegas em adotá-lo, então por enquanto estou seguindo com projetos que consigo tocar sozinho
  • Não há cronograma oficial para o 1.0
    Como referência, este vídeo pode ser interessante