Zig Libc

 (ziglang.org)
2 Punkte von GN⁺ 2026-02-04 | 1 Kommentare | Auf WhatsApp teilen
  • Die Programmiersprache Zig stellt die libc-Funktionalität direkt in der Zig-Standardbibliothek bereit und entfernt dabei schrittweise den bestehenden C-Quellcode
  • Bisher wurden etwa 250 C-Quelldateien gelöscht, 2032 sind noch übrig
  • Diese Umstellung bringt schnellere Kompilierung, geringere Installationsgröße und kleinere Binärdateien bei statischem Linking
  • Durch eine aktuelle Verbesserung wird zig libc nicht mehr als separates statisches Archiv, sondern innerhalb der Zig Compilation Unit (ZCU) gemeinsam mit anderem Code optimiert, wodurch Duplikate entfernt und Optimierungen auf LTO-Niveau möglich werden
  • Da Zig zu einem eigenen Anbieter einer statischen libc wird, sollten bei entsprechenden Problemen Bug-Reports direkt an das Zig-Projekt gesendet werden

Überblick über das Zig-libc-Projekt

  • Mehrere Mitwirkende arbeiten am zig-libc-Teilprojekt, das die bisherige C-basierte libc-Implementierung durch Wrapper in der Zig-Standardbibliothek ersetzt
    • Ziel ist es, doppelten C-Code zu entfernen und Funktionen wie memcpy, atan2 als einfache Zuordnungen oder wie strnlen als allgemeine Funktions-Wrapper bereitzustellen
    • Die Funktion strnlen wird zum Beispiel mit Zigs std.mem.findScalar implementiert
  • Bislang wurden etwa 250 C-Quelldateien gelöscht, 2032 bleiben noch übrig

Performance- und Strukturverbesserungen

  • Mit jeder nach Zig migrierten Funktion sinken die Abhängigkeiten von externen Projekten und der Programmiersprache C
    • Das führt zu höherer Kompiliergeschwindigkeit, einfacherer und kleinerer Installation sowie kleineren Binärdateien statisch gelinkter Benutzeranwendungen
  • Durch die jüngste Änderung wird zig libc innerhalb der Zig Compilation Unit (ZCU) zusammen mit anderem Zig-Code kompiliert
    • Statt als separates statisches Archiv gelinkt zu werden, nutzt es die integrierte Struktur aus Compiler und Linker
    • Dadurch werden Entfernung doppelten Codes und funktionsübergreifende Optimierungen möglich
    • Das ähnelt der Link Time Optimization (LTO), findet jedoch nicht in der Linker-Phase, sondern im Frontend statt

Künftige Erweiterungsmöglichkeiten

  • In Verbindung mit den jüngsten std.Io-Änderungen könnte es künftig möglich werden, dass Nutzer das I/O-Verhalten der libc steuern
    • Beispiel: read- und write-Aufrufe in eine io_uring-Event-Loop integrieren
    • Auch Funktionen zur Erkennung von Resource Leaks könnten auf C-Code von Drittanbietern angewendet werden
    • Derzeit ist das allerdings noch eine ungetestete Idee

Tests und Qualitätssicherung

  • Das libc-test-Projekt von Szabolcs Nagy hilft erheblich dabei, Regressionen bei mathematischen Funktionen zu vermeiden
    • Mit diesem Testsatz wird die Korrektheit von Zig libc überprüft

Hinweise für Nutzer

  • Zig befindet sich im Übergang dazu, die Funktionen von musl, mingw-w64 und wasi-libc selbst bereitzustellen
    • Bei entsprechenden Problemen sollten Bug-Reports direkt an das Zig-Projekt gesendet werden
    • So soll verhindert werden, dass versehentlich falsche Issues an die Maintainer der bisherigen eigenständigen libc-Projekte gehen

Schluss

  • Der letzte Satz des Artikels endet mit „Abolish ICE“ (ohne weitere Erläuterung)

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-04
Hacker-News-Kommentare

  • 250 C-Dateien wurden gelöscht, und jetzt sind noch 2032 übrig
    Es ist auf lange Sicht ein ziemlich aufregendes Projekt, zu beobachten, wie Zig libc von innen heraus ersetzt

    • Das habe ich an Zig immer bewundert
      Viele Sprachen behaupten, C zu ersetzen, aber Zig war fast die einzige, die die C-ABI und das Build-System auf natürliche Weise integriert hat
      Auch die translate-c-Funktion arbeitet erstaunlich gut
      Ich denke, es war klüger, nicht wie C++ 99 % Kompatibilität erzwingen zu wollen, sondern die Einfachheit von C zu bewahren und zugleich die Fallstricke der Sprache zu vermeiden

  • Ich frage mich, ob das langfristig bedeutet, dass Zig nicht auf OpenBSD laufen wird
    OpenBSD blockiert direkte Syscalls und erzwingt Aufrufe nur über libc
    Siehe dazu diesen Thread

    • Das betrifft nur statisches libc
      Mit der Option -dynamic -lc werden die libc-Funktionen des Zielsystems bereitgestellt
      Es gibt auch Systeme wie macOS, die nur dynamisches libc unterstützen, und soweit ich weiß unterstützt OpenBSD auch statisches libc
    • Eine zugehörige Antwort gibt es hier

  • Das ist eine sehr interessante Veränderung daran, wie das Zig-Projekt C-Bibliotheken linkt
    Ich frage mich aber, ob man beim Cross-Kompilieren von C-Programmen für Windows mit MinGW in Zig weiterhin die libc von MinGW statisch linken kann

    • In diesem Fall ändert sich nichts
      Wenn man -target x86_64-windows-gnu -lc angibt, werden einige libc-Funktionen von Zig und einige von der mitgelieferten mingw-w64 bereitgestellt
      Zig liefert alles ohne separate mingw-w64-Installation mit
      Wenn man möchte, kann man mit --libc libc.txt auch explizit ein externes libc angeben

  • Das ist zwar eine tolle Idee, aber ich mache mir Sorgen, ob man bei portiertem Code weiterhin CVE-Sicherheitslücken in glibc oder musl nachverfolgen muss

    • Dasselbe passiert bereits in der Standardbibliothek
      Bei gemeinsam genutzten Codepfaden wie etwa in der Mathematik gibt es sogar eher weniger potenzielle Bugs

  • Es gab die Beschreibung, das sei „ähnlich wie LTO über die libc-Grenze hinweg zu aktivieren, nur dass es im Frontend richtig gemacht wird und nicht im Linker“
    Ich frage mich, warum es in der Linker-Phase zu spät ist und ob Zig mehr optimieren kann als ein Linker auf LLVM-IR-Ebene

    • Im Frontend sind Inlining und Dead-Code-Eliminierung möglich
      In optimierten statischen Bibliotheken sind solche Optimierungen zur Link-Zeit schwierig

  • In Kombination mit den jüngsten std.Io-Änderungen ist interessant, dass Benutzer das I/O-Verhalten von libc direkt steuern können
    Zum Beispiel indem alle read/write-Aufrufe in eine io_uring-Event-Loop eingebunden werden
    Mich persönlich interessiert eher kqueue, aber dieses Zitat scheint auch darauf anwendbar zu sein

  • libc hat viele furchteinflößende Teile, aber das ist wirklich ein interessantes Projekt

    • Natürlich gibt es auch nützliche Funktionen
      Zum Beispiel Dinge wie „memfrob“ oder „strfry“ — als Witz gemeint, aber so etwas gibt es eben nur in glibc :)

  • Ich frage mich, ob es so etwas auch für Rust gibt
    Ich will keine Zig-vs.-Rust-Debatte anfangen, sondern würde in Rust-Projekten ebenfalls gern eine unabhängigere Umgebung schaffen

    • Auch für Rust gibt es einige libc-Implementierungen
      • c-ward: eine in Rust geschriebene libc-Implementierung
      • relibc: für Redox OS, funktioniert aber auch unter Linux
      • rustix: bindet sicher an die POSIX-API, ohne C zu verwenden

  • Ich frage mich, ob jemand weiß, wann Zig die Version 1.0 erreichen wird
    Ich interessiere mich sehr für die Sprache, aber es gibt noch viele Änderungen, daher zögere ich, sie für wichtige Projekte zu verwenden

    • Niemand weiß das genau
      Trotzdem kommen große Produktionsprojekte wie Bun, Ghostty und Tigerbeetle gut damit zurecht
      Die Semantik von Zig ist einfach, daher muss man bei Versionsupdates meist nur den Compiler aktualisieren und ein paar mechanische Änderungen vornehmen
      Was mich eher aufhält, ist nur die Bereitschaft meiner Kollegen, es zu übernehmen, deshalb arbeite ich erst einmal an Projekten, die ich allein umsetzen kann
    • Es gibt keinen offiziellen Zeitplan für 1.0
      Zur Referenz könnte dieses Video interessant sein