छह साल के काम और 360 पैचों के बाद Linux ने `strncpy` API को समाप्त किया

Null-Terminated Strings बनाम Length-Prefixed / “Real” String Types

• कई लोग तर्क देते हैं कि NUL-terminated C strings computing के सबसे खराब design choices में से एक हैं: overflow करना आसान, reason करना कठिन, और performance traps पैदा करने वाले (जैसे strlen को बार-बार चलाने से O(N) O(N²) में बदल जाता है)।
• दूसरे लोग नोट करते हैं कि 1970s के छोटे machines पर यह एक pragmatic trade-off था; sentinel-terminated sequences (strings, pointer arrays, linked lists) सस्ते थे और assembly practice से मेल खाते थे।
• Pascal-style या length-prefixed strings missing-terminator bugs से बचाते हैं, लेकिन समस्याएँ लाते हैं: fixed-size length fields (historically 255 chars), bytes/codepoints/glyphs के बीच भ्रम, और copying के बिना substrings करना कठिन होना, जब तक कि आप “fat pointers” (pointer+length) की ओर न जाएँ।
• Modern variants पर चर्चा हुई: D का struct { size_t length; T* ptr; }, BSTRs और Pascal/Delphi/Free Pascal headers, dynamic/variable-length length encodings, और “span”/slice types। Trade-offs: memory overhead बनाम speed बनाम zero-copy slicing.

NULL, NUL, और Option Types

• Thread बार-बार NUL (byte 0 terminator) और NULL (invalid pointer) के बीच अंतर स्पष्ट करता है।
• कुछ लोगों के लिए NULL ठीक और आवश्यक है; असली समस्या non-null pointers declare न कर पाना है।
• दूसरे लोग modern “option”/sum types (जैसे Option<T>) पर ज़ोर देते हैं, जो compile time पर type system द्वारा “unset” values को represent करने का सही तरीका हैं।
• इस पर बहस है कि क्या low-level environments NULL को ऐसे constructs से replace कर सकते हैं या करना चाहिए, बनाम उन्हें एक higher-level abstraction के रूप में उपयोग करना चाहिए जो नीचे जाकर null-able representations में compile हो जाए।

Historical और Standards Context

• कई comments C की origins पर ज़ोर देते हैं: tiny RAM (दसियों KiB), single-pass compilers, PDP-11 addressing limits, और existing idioms का reuse। उस संदर्भ में null-terminated strings और pointer/array decay clever compromises माने जाते थे, mistakes नहीं।
• Fat pointers/slices और safer APIs (जैसे strlcpy) जैसे बाद के प्रस्तावों को missed opportunities कहा गया; committees की आलोचना की गई कि उन्होंने complex features (VLAs, _Generic) जोड़ीं लेकिन C string model और stdlib को मूल रूप से frozen ही छोड़ दिया।

strncpy, Kernel APIs, और Safety

• strncpy को व्यापक रूप से misused और counterintuitive बताया गया: यह zeros से pad करता है, truncation पर NUL-terminate न भी करे, और मूल रूप से fixed-size, padded fields (जैसे पुराने directory entries) के लिए बनाया गया था, “safe strcpy” के रूप में नहीं।
• Kernel के replacement functions (strscpy, strscpy_pad, strtomem_pad, memcpy_and_pad, memcpy) स्पष्ट intent encode करते हैं (terminated बनाम non-terminated, padding बनाम raw copy), भले ही APIs अधिक हों, लेकिन safety और performance signaling बेहतर हो जाती है।
• कुछ लोगों को यह proliferation “convoluted” लगता है; दूसरे कहते हैं कि एक single “Swiss army knife” slower होगा और intent को धुंधला करेगा।

AI और Automated Refactoring

• चर्चा की एक पंक्ति पूछती है कि क्या LLM-based coders strncpy removal work का अधिकांश हिस्सा automate कर सकते थे।
• समर्थकों का अनुभव है कि उन्होंने LLMs का उपयोग करके बहुत सारे C programs refactor किए हैं, और उनका मानना है कि छह साल essentially mechanical changes के लिए बहुत लंबा समय है।
• skeptics जवाब देते हैं कि kernel-scale project में मुख्य bottlenecks review, coordination, और testing हैं, सिर्फ editing नहीं; subtle downstream behavior और पुराने semantics पर निर्भरता की सावधानीपूर्वक audit करनी पड़ती है।
• हर programming discussion में AI के घुस आने से स्पष्ट थकान दिखाई देती है, साथ ही बड़े-scale refactors के लिए इसकी संभावनाओं को लेकर जिज्ञासा भी है।