Zig Libc

• Zig भाषा libc functionality को सीधे Zig standard library में implement करने की दिशा में बढ़ रही है, और मौजूदा C source code को धीरे-धीरे हटा रही है
• अब तक लगभग 250 C source files हटाई जा चुकी हैं, और 2032 बाकी हैं
• इस बदलाव से compile speed में सुधार, installation size में कमी, और static linking के समय binary size में कमी जैसे प्रभाव मिल रहे हैं
• हालिया सुधार के कारण zig libc अब अलग static archive नहीं, बल्कि Zig Compilation Unit (ZCU) के भीतर दूसरे code के साथ optimize होती है, जिससे duplicate code removal और LTO-स्तर के optimization संभव होते हैं
• Zig के अपने static libc provider में बदलने के साथ, संबंधित समस्या होने पर सीधे Zig project में bug report submit करना ज़रूरी है

---

Zig libc प्रोजेक्ट का अवलोकन

• कई contributors zig libc subproject में शामिल होकर मौजूदा C-आधारित libc implementation को Zig standard library wrappers से बदल रहे हैं
  • लक्ष्य है duplicated C code को हटाना, और memcpy, atan2 जैसे simple mapping functions या strnlen जैसे सामान्य function wrapping के रूप में उपलब्ध कराना
  • उदाहरण के तौर पर strnlen function को Zig के std.mem.findScalar का उपयोग करके implement किया गया है
• अब तक लगभग 250 C source files हटाई जा चुकी हैं, और 2032 बाकी हैं

प्रदर्शन और संरचनात्मक सुधार

• हर function के Zig में बदले जाने के साथ external projects और C language dependencies कम हो रही हैं
  • इससे compile speed बेहतर, installation size सरल और छोटी, और statically linked user applications की binary size कम हो रही है
• हालिया बदलाव के कारण zig libc को Zig Compilation Unit (ZCU) के भीतर दूसरे Zig code के साथ compile किया जाता है
  • इसे अलग static archive के रूप में link नहीं किया जाता, बल्कि compiler और linker की integrated architecture का उपयोग किया जाता है
  • इससे duplicate code removal और functions के बीच optimization संभव होती है
  • यह link time optimization (LTO) जैसा है, लेकिन linker stage के बजाय frontend stage में किया जाता है

भविष्य के विस्तार की संभावना

• हालिया std.Io changes के साथ मिलकर libc के I/O behavior को user द्वारा control करने की संभावना है
  • उदाहरण: read, write calls को io_uring event loop में integrate करना
  • resource leak detection features को third-party C code पर भी लागू करना संभव हो सकता है
  • हालांकि, फिलहाल यह अभी परखा नहीं गया, केवल idea stage में है

टेस्टिंग और गुणवत्ता आश्वासन

• Szabolcs Nagy का libc-test project math functions में regression रोकने में बहुत मददगार रहा है
  • इसी test set से Zig libc की correctness verify की जाती है

उपयोगकर्ता मार्गदर्शन

• Zig musl, mingw-w64, wasi-libc functionality को खुद provide करने के चरण में है
  • संबंधित समस्या होने पर सीधे Zig project में bug report submit करनी चाहिए
  • इसका उद्देश्य मौजूदा independent libc project maintainers तक गलत issue पहुँचने से रोकना है

समापन

• लेख की आखिरी पंक्ति “Abolish ICE” से समाप्त होती है (कोई अतिरिक्त व्याख्या नहीं)

[GN⁺]

Hacker News की टिप्पणियाँ

• 250 C फ़ाइलें हटा दी गईं, और अब 2032 बची हैं
  लंबे समय में Zig को libc को अंदर से replace करते देखना काफ़ी रोमांचक प्रोजेक्ट है

  • मैं Zig की इस बात की हमेशा से प्रशंसा करता आया हूँ
    कई भाषाएँ खुद को C का replacement बताती हैं, लेकिन वास्तव में C ABI और build system को स्वाभाविक रूप से integrate करने वाला Zig लगभग अकेला रहा है
    translate-c फीचर भी हैरान कर देने वाली हद तक अच्छी तरह काम करता है
    C++ की तरह 99% compatibility बनाए रखने की कोशिश न करके, C की सादगी को बचाए रखते हुए भाषा के pitfalls से बचने का फ़ैसला मुझे ज़्यादा समझदारी भरा लगता है

• सोच रहा हूँ कि क्या लंबे समय में इसका मतलब यह है कि Zig OpenBSD पर नहीं चलेगा
  OpenBSD सीधे syscall को रोकता है और केवल libc के ज़रिए call करने को enforce करता है
  संबंधित जानकारी के लिए इस थ्रेड को देखें

  • यह सिर्फ़ static libc पर लागू होता है
    -dynamic -lc option देने पर target system के libc functions उपलब्ध हो जाते हैं
    macOS जैसे कुछ systems केवल dynamic libc को support करते हैं, और मेरी जानकारी में OpenBSD static libc को भी support करता है
  • संबंधित जवाब यहाँ देखा जा सकता है

• Zig प्रोजेक्ट द्वारा C लाइब्रेरी लिंक करते समय यह बहुत दिलचस्प बदलाव है
  लेकिन मैं सोच रहा हूँ कि MinGW इस्तेमाल करने वाले Windows के लिए C programs को Zig से cross-compile करते समय, क्या अब भी MinGW की libc को statically link किया जा सकता है

  • इस मामले में कोई बदलाव नहीं है
    -target x86_64-windows-gnu -lc देने पर कुछ libc functions Zig देता है, और कुछ vendored mingw-w64 देता है
    अलग से mingw-w64 install किए बिना Zig सब कुछ उपलब्ध कराता है
    चाहें तो --libc libc.txt से external libc को सीधे specify भी कर सकते हैं

• आइडिया शानदार है, लेकिन चिंता है कि port किए गए code के लिए क्या glibc या musl की CVE vulnerabilities को लगातार track करना पड़ेगा

  • वही काम standard library में भी पहले से किया जा रहा है
    math जैसे shared code paths में तो उल्टा संभावित bugs कम हो जाते हैं

• एक व्याख्या थी: “यह libc boundary के पार LTO enable करने जैसा है, लेकिन linker की बजाय frontend में सही तरीके से किया जाता है”
  जानना चाहता हूँ कि linker stage पर यह बहुत देर क्यों हो जाती है, और क्या Zig LLVM IR level linker से ज़्यादा optimization कर सकता है

  • frontend में inlining और dead code elimination संभव है
    optimized static libraries में link time पर इस तरह की optimization करना कठिन होता है

• हाल के std.Io बदलावों के साथ मिलाकर देखें तो, libc के I/O behavior को user द्वारा सीधे control किया जा सकता है, यह दिलचस्प है
  उदाहरण के लिए सभी read/write calls को io_uring event loop में शामिल करना
  मुझे व्यक्तिगत रूप से kqueue में ज़्यादा रुचि है, लेकिन लगता है यह उद्धरण वहाँ भी लागू होगा

• libc में कई डरावने हिस्से हैं, लेकिन यह सचमुच दिलचस्प प्रोजेक्ट है

  • बेशक इसमें उपयोगी functions भी हैं
    जैसे "memfrob" या "strfry", हालांकि मज़ाक में कह रहा हूँ, ऐसी चीज़ें सिर्फ़ glibc में हैं :)

• सोच रहा हूँ कि क्या Rust में भी ऐसा कुछ है
  Zig vs Rust बहस शुरू करने का इरादा नहीं है, बस Rust projects में भी थोड़ा और independent environment बनाना चाहता हूँ

  • Rust में भी libc की कुछ implementations हैं
    • c-ward: Rust में लिखी गई libc implementation
    • relibc: Redox OS के लिए, लेकिन Linux पर भी काम करती है
    • rustix: C का उपयोग किए बिना POSIX API के लिए safe bindings देता है

• क्या किसी को पता है कि Zig 1.0 version तक कब पहुँचेगा
  भाषा में काफ़ी दिलचस्पी है, लेकिन अभी इसमें बहुत बदलाव हो रहे हैं, इसलिए महत्वपूर्ण projects में इस्तेमाल करने से हिचकिचाहट है

  • किसी को ठीक-ठीक नहीं पता
    फिर भी Bun, Ghostty, Tigerbeetle जैसे बड़े production projects इसे अच्छी तरह follow कर रहे हैं
    Zig की semantics सरल हैं, इसलिए version upgrade के समय अक्सर सिर्फ़ compiler update करना और कुछ mechanical fixes करना काफ़ी होता है
    मुझे रोकने वाली चीज़ सिर्फ़ मेरे साथ काम करने वालों की adoption willingness है, इसलिए अभी मैं उन projects पर काम कर रहा हूँ जिन्हें अकेले बना सकता हूँ
  • 1.0 के लिए कोई official schedule नहीं है
    संदर्भ के लिए यह वीडियो दिलचस्प हो सकता है