Libc de Zig

• Le langage Zig est en train d’évoluer vers une implémentation directe des fonctionnalités de libc dans la bibliothèque standard Zig, en supprimant progressivement l’ancien code source en C
• À ce jour, environ 250 fichiers source C ont été supprimés, et il en reste 2032
• Cette transition apporte notamment une amélioration de la vitesse de compilation, une réduction de la taille d’installation et une diminution de la taille des binaires lors de l’édition de liens statique
• Une amélioration récente permet à zig libc d’être optimisée avec d’autres morceaux de code à l’intérieur d’une Zig Compilation Unit (ZCU), plutôt que comme archive statique séparée, ce qui rend possible l’élimination du code dupliqué et des optimisations de niveau LTO
• Avec la transition de Zig vers son propre rôle de fournisseur de libc statique, il faut désormais soumettre directement les rapports de bugs au projet Zig en cas de problème connexe

---

Vue d’ensemble du projet Zig libc

• Plusieurs contributeurs participent au sous-projet zig libc afin de remplacer l’implémentation libc existante en C par des wrappers de la bibliothèque standard Zig
  • L’objectif est de supprimer le code C redondant et de fournir soit des fonctions de mappage simple comme memcpy, atan2, soit des wrappers de fonctions plus générales comme strnlen
  • Par exemple, la fonction strnlen est implémentée à l’aide de std.mem.findScalar de Zig
• Jusqu’à présent, environ 250 fichiers source C ont été supprimés, et 2032 restent encore

Améliorations de performance et de structure

• À mesure que chaque fonction est convertie vers Zig, les dépendances aux projets externes et au langage C diminuent
  • Cela entraîne une hausse de la vitesse de compilation, une simplification et une réduction de la taille d’installation, ainsi qu’une réduction de la taille des binaires des applications utilisateur liées statiquement
• Un changement récent fait que zig libc est compilée à l’intérieur d’une Zig Compilation Unit (ZCU) avec le reste du code Zig
  • Au lieu d’être liée comme archive statique distincte, elle exploite la structure intégrée du compilateur et de l’éditeur de liens
  • Cela permet l’élimination du code dupliqué et l’optimisation inter-fonctions
  • C’est similaire à l’optimisation au moment de l’édition de liens (LTO), mais réalisé à l’étape du front-end plutôt qu’à celle du linker

Possibilités d’extension futures

• Combiné aux récents changements de std.Io, cela pourrait permettre à l’utilisateur de contrôler le comportement d’E/S de libc
  • Exemple : intégrer les appels read et write dans une boucle d’événements io_uring
  • Il serait aussi possible d’appliquer des fonctions de détection des fuites de ressources à du code C tiers
  • Cependant, cela reste pour l’instant au stade d’idée non expérimentée

Tests et assurance qualité

• Le projet libc-test de Szabolcs Nagy aide grandement à prévenir les régressions sur les fonctions mathématiques
  • Cet ensemble de tests sert à vérifier la précision de Zig libc

Informations pour les utilisateurs

• Zig est en train d’évoluer vers une étape où il fournit lui-même les fonctionnalités de musl, mingw-w64 et wasi-libc
  • En cas de problème connexe, il faut soumettre directement un rapport de bug au projet Zig
  • L’objectif est d’éviter que des tickets erronés soient transmis aux mainteneurs des projets libc indépendants

Conclusion

• La dernière phrase du billet est : « Abolish ICE » (sans explication supplémentaire)

[GN⁺]

Avis sur Hacker News

• 250 fichiers C ont été supprimés, et il en reste maintenant 2032
  Observer la manière dont Zig remplace libc de l’intérieur est un projet assez exaltant sur le long terme

  • C’est un aspect de Zig que j’ai toujours admiré
    Beaucoup de langages prétendent remplacer C, mais Zig a été presque le seul à intégrer naturellement l’ABI C et le système de build
    La fonctionnalité translate-c marche aussi étonnamment bien
    Je pense qu’il a été plus judicieux de ne pas chercher à maintenir une compatibilité à 99 % comme C++, mais de préserver la simplicité de C tout en évitant les pièges du langage

• Je me demande si cela signifie qu’à long terme Zig ne fonctionnera pas sur OpenBSD
  OpenBSD bloque les appels système directs et impose de passer uniquement par libc
  Voir ce fil à ce sujet

  • Cela ne concerne que la libc statique
    Avec l’option -dynamic -lc, les fonctions libc du système cible sont fournies
    Il existe aussi des systèmes comme macOS qui ne prennent en charge que la libc dynamique, et il me semble qu’OpenBSD prend également en charge la libc statique
  • On peut consulter la réponse correspondante ici

• C’est une évolution très intéressante pour la façon dont le projet Zig lie les bibliothèques C
  Mais je me demande si, lors d’une compilation croisée vers Zig d’un programme C Windows utilisant MinGW, il est toujours possible de lier statiquement la libc de MinGW

  • Dans ce cas, rien ne change
    En spécifiant -target x86_64-windows-gnu -lc, certaines fonctions libc sont fournies par Zig, et d’autres par le mingw-w64 embarqué
    Zig fournit tout sans installation séparée de mingw-w64
    Si on le souhaite, on peut aussi indiquer directement une libc externe avec --libc libc.txt

• C’est une idée géniale, mais je m’inquiète du fait qu’il faudra continuer à suivre les vulnérabilités CVE de glibc ou musl pour le code porté

  • C’est déjà la même chose dans la bibliothèque standard
    Sur les chemins de code partagés, comme les maths, cela réduit même potentiellement le nombre de bugs

• Il y avait cette explication disant que c’est « semblable à l’activation de la LTO au-delà de la frontière libc, mais faite correctement dans le frontend plutôt que par le linker »
  Je me demande pourquoi l’étape de l’édition de liens arrive trop tard, et si Zig peut faire davantage d’optimisations qu’un linker au niveau LLVM IR

  • Dans le frontend, il est possible de faire de l’inlining et de l’élimination de code mort
    Dans une bibliothèque statique optimisée, ces optimisations sont difficiles au moment de l’édition de liens

• Combiné aux récents changements de std.Io, il est intéressant que l’utilisateur puisse contrôler directement le comportement d’E/S de libc
  Par exemple, en faisant participer tous les appels read/write à une boucle d’événements io_uring
  Personnellement, je m’intéresse davantage à kqueue, mais cette citation semble aussi s’appliquer à ce cas

• libc contient des parties effrayantes, mais c’est vraiment un projet fascinant

  • Bien sûr, il y a aussi des fonctions utiles
    Par exemple des choses comme "memfrob" ou "strfry", même si c’est une blague, ce genre de choses n’existe que dans glibc :)

• Je me demande si Rust a quelque chose de ce genre
  Je ne cherche pas à lancer un débat Zig vs Rust, mais j’aimerais aussi créer un environnement plus indépendant dans des projets Rust

  • Rust a aussi quelques implémentations de libc
    • c-ward : une implémentation de libc écrite en Rust
    • relibc : destinée à Redox OS, mais fonctionne aussi sur Linux
    • rustix : fournit des bindings sûrs vers l’API POSIX sans utiliser C

• Je me demande si quelqu’un sait quand Zig atteindra la version 1.0
  Le langage m’intéresse beaucoup, mais il évolue encore trop pour que j’ose l’utiliser dans un projet important

  • Personne ne le sait exactement
    Cela dit, de gros projets en production comme Bun, Ghostty et Tigerbeetle suivent bien le rythme
    La sémantique de Zig est simple, donc lors d’une montée de version, il suffit généralement de mettre à jour le compilateur et d’appliquer quelques modifications mécaniques
    Ce qui me freine, c’est surtout la volonté d’adoption de mes collègues, donc pour l’instant je me concentre sur des projets que je peux construire seul
  • Il n’y a pas de calendrier officiel pour la 1.0
    À titre indicatif, cette vidéo peut être intéressante