GCC 14 में पोर्टिंग: C भाषा संबंधी मुद्दे

मूल लेख ↗ Hacker News चर्चा ↗

GCC 14 की आधुनिक C मानकों के प्रति अधिक सख्त अनुरूपता लंबे समय से मौजूद चेतावनियों—जैसे implicit `int`, घोषित न की गई functions, और कुछ pointer mismatches—को त्रुटियों में बदल रही है, जिससे autoconf जैसे build systems और बड़े codebases में बदलाव करना पड़ रहा है। टिप्पणीकार बेहतर सुरक्षा, स्पष्ट diagnostics, और C99/C23 सुविधाओं (जैसे variable-length array types) के देर से अपनाए जाने के लाभों को legacy और “portable” C के टूटने की लागत के विरुद्ध तौलते हैं, जो pre-ANSI या compiler-specific व्यवहार पर निर्भर था। थ्रेड integer और pointer type semantics, calling conventions, और यह क्यों कि कुछ C features दशकों पहले standard होने के बावजूद इतनी धीरे विकसित हुईं, जैसे गहरे language design मुद्दों में भी जाता है।

GCC 14 के अधिक सख्त C डिफ़ॉल्ट्स

  • GCC 14 कई लंबे समय से मौजूद C चेतावनियों को त्रुटियों में बदल देता है (जैसे implicit function declarations, implicit int, और कुछ incompatible pointer उपयोग)।
  • कई टिप्पणीकार इसे बहुत देर से आया बदलाव मानते हैं: ये संरचनाएँ दशकों से व्यावहारिक रूप से अप्रचलित हैं और आधुनिक कोड में लगभग कभी जानबूझकर नहीं होतीं।
  • अन्य लोग टूट-फूट की ओर ध्यान दिलाते हैं: पुराना कोड (जिसमें IOCCC प्रविष्टियाँ और ऐतिहासिक GNU userland शामिल हैं) तब तक विफल होगा जब तक errors को downgrade न किया जाए। GCC अभी भी पुराने व्यवहार को वापस लाने के लिए flags की अनुमति देता है।

Variable Length Arrays (VLAs) और C23

  • थ्रेड में C99 (VLAs अनिवार्य), C11 (VLAs वैकल्पिक), और C23 (VLA types फिर से अनिवार्य; VLA objects with automatic storage अभी भी वैकल्पिक) पर चर्चा होती है।
  • स्पष्ट किया गया कि कंपाइलरों को variably-modified types की syntax और semantics का समर्थन करना होगा (जैसे उन पर sizeof और offsetof), लेकिन वे stack-based VLAs को फिर भी छोड़ सकते हैं।
  • कार्यान्वयन की जटिलता पर बहस: runtime-dependent layouts और typedefs “सिर्फ alloca sugar” से आगे अतिरिक्त semantic machinery लाते हैं।
  • MSVC में अभी भी VLAs का समर्थन नहीं है और उसने C99 को पूरी तरह छोड़ दिया था, जिससे VLAs का portable उपयोग सीमित रहता है।

डिस्ट्रोज़ में पोर्टिंग का काम

  • Fedora और अन्य ने सख्त डिफ़ॉल्ट्स की तैयारी के लिए पहले ही बड़े पैमाने पर सफ़ाई की है, जिसमें autoconf-जनित परीक्षणों का भारी प्रभाव पड़ा जो संदिग्ध C कोड का उपयोग करते हैं और चेतावनियों को छिपाते हैं।
  • मुख्य जोखिम “silent feature loss” था: builds सफल हो जाते हैं लेकिन configure checks विफल होते हैं, जिससे सुविधाएँ निष्क्रिय हो जाती हैं। इससे config diffing approaches सामने आईं।
  • Clang/Xcode के अधिक सख्त डिफ़ॉल्ट्स और Gentoo द्वारा fixes को upstream करना GCC को सख्त करने के लिए सहमति बनाने में मददगार रहा।

पुराने C constructs और compilation मॉडल

  • Pre-ANSI C में घोषित न की गई functions को कॉल करने की अनुमति थी, और उन्हें int लौटाने वाला माना जाता था; यह तब “काफ़ी हद तक” काम करता था जब sizeof(int) == sizeof(pointer) होता था।
  • इस पर चर्चा कि एक-pass compilers अभी तक घोषित न हुई functions को कैसे संभालते थे, और क्या अतिरिक्त checking का मतलब “second pass” होगा।
  • कुछ लोग सुझाव देते हैं कि भाषा में अधिक flexible forward referencing को आधिकारिक समर्थन मिलना चाहिए, नए compiler infrastructures का हवाला देते हुए जहाँ यह “बस काम करता है।”

Integer types, word size, और style

  • इस पर लंबी चर्चा कि 64-bit systems पर int 32-bit क्यों बना रहा: backward compatibility, standard integer ladder की सीमाएँ, और मौजूदा code assumptions।
  • int को कभी 64-bit बनाने के पक्ष और विपक्ष में तर्क: portability बनाम memory/cache footprint बनाम clarity।
  • “standard” integer types (char/short/int/long/long long) और “extended” integer types के बीच अंतर; ध्यान दें कि stdint.h अधिकतर पहले वाले को typedef करता है, वास्तव में नई widths नहीं बनाता।
  • अलग-अलग प्रथाएँ: कुछ लोग fixed-width types (int32_t, int64_t) को पसंद करते हैं, जबकि अन्य int + long long को प्राथमिकता देते हैं और numbered types से aesthetics तथा overload issues (C++ में) के कारण बचते हैं।

Function pointers, void*, और pointer representations

  • सवाल कि const char* लेने वाले function को उस जगह क्यों नहीं इस्तेमाल किया जा सकता जहाँ int (*)(const void*, const void*) प्रकार का function pointer अपेक्षित है।
  • मानक arbitrary function pointer conversions को मना करता है; C में एक generic function pointer type भी नहीं है।
  • C11 यह गारंटी देता है कि void* और character pointers का representation और alignment समान हो; अन्य pointer types का ऐसा होना ज़रूरी नहीं, और function pointers object pointers से अलग हो सकते हैं।
  • ऐतिहासिक और असामान्य architectures, जहाँ pointer sizes और addressing modes एकसमान नहीं होते, इस बात के कारणों के रूप में दिए जाते हैं कि standard क्यों सख्त बना रहता है।

Backward compatibility बनाम विशिष्ट उपयोग के मामले

  • कुछ लोग “anti-C89” दिशा की आलोचना करते हैं, यह तर्क देते हुए कि implicit int हटाने से रचनात्मक polyglot उपयोग (जैसे C/JavaScript dual code) बिना किसी स्पष्ट लाभ के प्रभावित होते हैं।
  • थ्रेड में अधिकांश मत बेहतर defaults के पक्ष में है ताकि subtle रूप से टूटा हुआ code रोका जा सके, जबकि legacy या contest-style programs के लिए escape hatches बने रहें।