Libc de Zig

• El lenguaje Zig está cambiando de dirección para implementar la funcionalidad de libc directamente en la biblioteca estándar de Zig, eliminando gradualmente el código fuente existente en C
• Hasta ahora se han eliminado alrededor de 250 archivos fuente en C, y quedan 2032
• Esta transición produce efectos como mejoras en la velocidad de compilación, reducción del tamaño de instalación y disminución del tamaño de los binarios al enlazar estáticamente
• Con una mejora reciente, zig libc se optimiza junto con otro código dentro de la Unidad de Compilación de Zig (ZCU), en lugar de ser un archivo estático separado, lo que permite eliminación de código duplicado y optimizaciones de nivel LTO
• A medida que Zig avanza para convertirse en su propio proveedor de libc estática, cuando surjan problemas relacionados será necesario enviar reportes de errores directamente al proyecto Zig

---

Resumen del proyecto Zig libc

• Varios contribuidores participan en el subproyecto zig libc, reemplazando la implementación existente de libc basada en C por envoltorios de la biblioteca estándar de Zig
  • El objetivo es eliminar código C duplicado y ofrecer funciones como memcpy, atan2 y otras como mapeos simples, o como envoltorios de funciones comunes como strnlen
  • Por ejemplo, la función strnlen está implementada usando std.mem.findScalar de Zig
• Hasta ahora se han eliminado alrededor de 250 archivos fuente en C y quedan 2032

Mejoras de rendimiento y estructura

• A medida que cada función se migra a Zig, disminuye la dependencia de proyectos externos y del lenguaje C
  • Esto genera mejoras en la velocidad de compilación, simplificación y reducción del tamaño de instalación y reducción del tamaño de los binarios de aplicaciones de usuario enlazadas estáticamente
• Un cambio reciente permite que zig libc se compile dentro de la Unidad de Compilación de Zig (ZCU) junto con otro código Zig
  • En lugar de enlazarse como un archivo estático separado, aprovecha la estructura integrada del compilador y el enlazador
  • Gracias a esto, es posible la eliminación de código duplicado y la optimización entre funciones
  • Esto es similar a la optimización en tiempo de enlace (LTO), pero se realiza en la etapa del frontend y no en la del enlazador

Posibilidades de expansión futura

• Si se combina con los cambios recientes en std.Io, podría existir la posibilidad de que el usuario controle el comportamiento de E/S de libc
  • Ejemplo: integrar las llamadas read y write en un bucle de eventos de io_uring
  • También sería posible aplicar funciones de detección de fugas de recursos incluso a código C de terceros
  • Sin embargo, por ahora sigue siendo una idea en etapa experimental

Pruebas y aseguramiento de calidad

• El proyecto libc-test de Szabolcs Nagy ha sido de gran ayuda para evitar regresiones en funciones matemáticas
  • Este conjunto de pruebas se usa para verificar la precisión de Zig libc

Guía para usuarios

• Zig está avanzando hacia una etapa en la que proporciona por sí mismo la funcionalidad de musl, mingw-w64 y wasi-libc
  • Si surgen problemas relacionados, será necesario enviar reportes de errores directamente al proyecto Zig
  • Esto busca evitar que lleguen incidencias incorrectas a los mantenedores de proyectos libc independientes existentes

Cierre

• La última frase del texto concluye con “Abolish ICE” (sin explicación adicional)

[GN⁺]

Comentarios en Hacker News

• Se eliminaron 250 archivos C, y ahora quedan 2032
  Ver cómo Zig va reemplazando libc desde adentro es un proyecto bastante emocionante a largo plazo

  • Siempre he admirado este aspecto de Zig
    Muchos lenguajes dicen que reemplazan a C, pero Zig fue de los pocos que realmente integró de forma natural el ABI de C y el sistema de build
    La función translate-c también funciona sorprendentemente bien
    Creo que fue una decisión más inteligente no intentar mantener un 99% de compatibilidad como C++, sino conservar la simplicidad de C evitando las trampas del lenguaje

• Me pregunto si esto significa que, a largo plazo, Zig no podrá ejecutarse en OpenBSD
  OpenBSD bloquea las syscalls directas y obliga a hacerlas solo a través de libc
  Para más contexto, ver este hilo

  • Esto solo aplica a libc estática
    Si se usa la opción -dynamic -lc, se proporcionan las funciones libc del sistema objetivo
    Hay sistemas como macOS que solo admiten libc dinámica, y según entiendo OpenBSD también soporta libc estática
  • Se puede ver una respuesta relacionada aquí

• Es un cambio muy interesante en cómo el proyecto Zig enlaza bibliotecas C
  Pero me pregunto si, al compilar de forma cruzada programas C para Windows usando MinGW con Zig, todavía se puede enlazar estáticamente la libc de MinGW

  • En este caso no hay cambios
    Si se especifica -target x86_64-windows-gnu -lc, algunas funciones libc las proporciona Zig y otras vendored mingw-w64
    Zig proporciona todo sin necesidad de una instalación aparte de mingw-w64
    Si se quiere, también se puede indicar manualmente una libc externa con --libc libc.txt

• Aunque es una idea genial, me preocupa si habrá que seguir rastreando las vulnerabilidades CVE de glibc o musl para el código portado

  • Ya se hace lo mismo en la biblioteca estándar
    En rutas de código compartidas como las matemáticas, incluso podría haber menos bugs potenciales

• Había una explicación que decía que esto es “similar a habilitar LTO más allá del límite de libc, pero hecho correctamente en el frontend y no en el linker”
  Me pregunto por qué en la etapa del linker ya es demasiado tarde, y si Zig puede hacer más optimizaciones que un linker a nivel de LLVM IR

  • En el frontend se pueden hacer inlining y eliminación de código muerto
    En bibliotecas estáticas ya optimizadas es difícil hacer ese tipo de optimizaciones en link time

• Combinado con los cambios recientes en std.Io, es interesante que el usuario pueda controlar directamente el comportamiento de I/O de libc
  Por ejemplo, haciendo que todas las llamadas read/write participen en un event loop de io_uring
  Personalmente me interesa más kqueue, pero parece que esta cita también aplicaría ahí

• Hay muchas partes aterradoras en libc, pero este proyecto sí que es realmente interesante

  • Claro, también hay funciones útiles
    Por ejemplo cosas como "memfrob" o "strfry", aunque es broma, esas solo están en glibc :)

• Me pregunto si Rust tiene algo parecido
  No busco iniciar una discusión Zig vs Rust, solo me gustaría tener un entorno más independiente también en proyectos Rust

  • Rust también tiene varias implementaciones de libc
    • c-ward: implementación de libc escrita en Rust
    • relibc: es para Redox OS, pero también funciona en Linux
    • rustix: hace bindings seguros a la API POSIX sin usar C

• Me pregunto si alguien sabe cuándo Zig llegará a la versión 1.0
  Me interesa mucho el lenguaje, pero todavía cambia bastante y me da duda usarlo en proyectos importantes

  • Nadie lo sabe con exactitud
    Aun así, grandes proyectos en producción como Bun, Ghostty y Tigerbeetle lo están siguiendo bien
    Como la semántica de Zig es simple, al subir de versión normalmente basta con actualizar el compilador y hacer unas cuantas correcciones mecánicas
    Lo único que me frena es la disposición de mis colegas a adoptarlo, así que por ahora avanzo con proyectos que puedo hacer yo solo
  • No hay un calendario oficial para 1.0
    Como referencia, este video podría ser interesante