मेमोरी सुरक्षा आवश्यक है, लेकिन पर्याप्त नहीं

सरकारी नीति और मेमोरी-सुरक्षित भाषाएँ

• US FY24 NDAA DoD को NSA के मेमोरी-सुरक्षित भाषाओं और टूल्स संबंधी मार्गदर्शन अपनाने का निर्देश देता है; NSA के उदाहरणों में C#, Go, Java, Ruby, Rust, Swift शामिल हैं।
• यह स्पष्ट नहीं है कि EU कानून में इसी तरह की स्पष्ट मेमोरी-सुरक्षा भाषा है या नहीं; एक EU impact assessment में Rust और Go का उल्लेख है, लेकिन आवश्यकताओं का नहीं।
• कुछ लोगों को उम्मीद है कि भविष्य के procurement rules सॉफ़्टवेयर की अधिक सख़्त जाँच लागू करेंगे, जिसमें संभवतः मेमोरी-सुरक्षा मानदंड और import controls भी शामिल होंगे।

Rust, “unsafe”, और अन्य भाषाओं से तुलना

• Rust का unsafe सामान्य FFI/Java/Swift के unsafe की तुलना में अधिक सीमित माना जाता है: type system मज़बूत lifetime और usage guarantees के साथ safe abstractions बनाने देता है।
• हालांकि, unsafe invariants के उल्लंघन पर C-जैसा undefined behavior फिर से ला देता है; bugs सूक्ष्म हो सकते हैं और दूर तक फैल सकते हैं।
• इस पर असहमति है कि क्या Rust कुल मिलाकर total defects घटाता है, या केवल उन्हें memory bugs से logic/panic-शैली की failures की ओर स्थानांतरित करता है; कुछ लोग formal studies की माँग करते हैं।
• Swift को Rust-जैसी ownership/borrowing की दिशा में बढ़ते हुए और tight C++ interop के माध्यम से “TypeScript for C++” के उम्मीदवार के रूप में रेखांकित किया गया है।
• Go और managed languages को लंबे समय से memory safety देने वाला बताया गया है, लेकिन उनके tradeoffs अलग हैं (GC, type system limitations, concurrency quirks)।

मेमोरी सुरक्षा बनाम समग्र correctness

• कई लोगों का तर्क है कि memory safety आवश्यक है लेकिन पर्याप्त नहीं: logic bugs, SQL injection, path traversal, crypto mistakes, और deserialization issues Rust सहित सभी भाषाओं में बने रहते हैं।
• कुछ लोग “panic culture” और graceful recovery की जगह crashing के अत्यधिक उपयोग को लेकर चिंतित हैं, खासकर non-security-critical contexts में।

Undefined behavior, C/C++, और optimization

• बड़े subthreads C के UB पर बहस करते हैं:
  • एक पक्ष: high optimization के लिए UB आवश्यक है (pointer provenance, aliasing, आदि)।
  • दूसरा पक्ष: कई UB मामलों को मामूली performance loss के साथ परिभाषित किया जा सकता है; modern compilers “adversarial” और बहुत जटिल हैं।
• ऐतिहासिक संदर्भ: C का design compiler implementation की आसानी और portability को safety और completeness से ऊपर रखता था; इससे इसके फैलने में मदद मिली, लेकिन unsafe की विरासत भी बनी।
• -fno-strict-aliasing जैसे flags और इसी तरह के विकल्प आंशिक mitigations के रूप में चर्चा में हैं, जिनकी कीमत non-standard dialects और कुछ performance होती है।

Data races और security

• इनमें अंतर किया गया है:
  • Low-level data races (non-atomic concurrent memory access) और
  • Higher-level race conditions (TOCTOU, distributed races)।
• कई लोग दावा करते हैं कि in-process data races अभी classic memory corruption की तुलना में exploited class के रूप में बड़ा मुद्दा नहीं हैं; अन्य लोग kernel और race-based exploits का उल्लेख करते हैं और तर्क देते हैं कि केवल rarity के कारण UB को सामान्य नहीं मानना चाहिए।
• कुछ लोग पूछते हैं कि languages data races को “लिखे गए मूल्यों में से एक” क्यों नहीं परिभाषित कर सकतीं; जवाब में tearing, compiler rematerialization, और lost optimizations का हवाला दिया जाता है।

Sandboxing, capabilities, और dependencies

• विशाल dependency trees और supply-chain risk को लेकर चिंता बढ़ रही है; libraries को process के भीतर sandbox करने के तरीकों की इच्छा है।
• प्रस्तावित mechanisms: language-level sandboxes (जैसे Java SecurityManager, GraalVM isolates), WebAssembly, और object-capability models जहाँ resources (filesystem, network) तक पहुँच capabilities के रूप में स्पष्ट रूप से पास की जाती है।

Python और अन्य “memory-safe” भाषाओं की सीमाएँ

• Python को सामान्यतः memory-safe कहा जाता है, लेकिन प्रतिभागी नोट करते हैं:
  • FFI (ctypes, C extensions) आसानी से safety तोड़ देती है।
  • Pure Python भी crafted bytecode या low-level APIs के माध्यम से interpreter memory errors ट्रिगर कर सकता है; इसे ठीक करने के लिए significant verification machinery की आवश्यकता होगी।
• सामान्य सहमति: “memory-safe language” एक व्यावहारिक लेबल है, जिसका अर्थ है “सामान्य उपयोग में सुरक्षित,” न कि पूर्ण गारंटी।

भविष्य की भाषा दिशाएँ और C++ उत्तराधिकारी

• चार “C++ successor” रणनीतियाँ पहचानी गईं: कुछ न करना, compatibility के भीतर safety जोड़ना, compatibility तोड़ना लेकिन unsafe रहना, या compatibility तोड़कर memory-safe by default होना।
• कुछ लोग half-measures पर सवाल उठाते हैं: यदि आप compatibility वैसे भी तोड़ रहे हैं, तो पूरी तरह memory-safe-by-default क्यों न जाएँ?
• systems languages के लिए design space दिखाई देता है जो memory-safe by default हों, लेकिन Rust से बहुत अलग निर्णय लें (stdlib scope, error handling, syntax, concurrency model, allocation policies, linking, package management)।