Rust borrow checker में 11 साल पुराना unsoundness बग मिला

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

Rust के borrow checker में 11 साल पुराना soundness bug मिला है, जिसमें lifetimes और एक custom `Drop` implementation वाला साधारण दिखने वाला code गलत तरीके से स्वीकार कर लिया जाता है और reference अपने data से ज़्यादा समय तक रह सकता है। टिप्पणीकार बताते हैं कि यह Rust के memory-safety वादे का उल्लंघन कैसे करता है, ज़ोर देते हैं कि यह language के type system की कमी नहीं बल्कि compiler implementation error है, और नोट करते हैं कि इसे वास्तविक exploit बनाने के लिए एक contrived destructor चाहिए। यह घटना इस व्यापक बहस को फिर भड़काती है कि C की तुलना में Rust वास्तव में कितना “safe” है, किसी भी type system या formal proof की सीमाएँ क्या हैं, और subtle compiler bugs खोजने में AI सहित tools की बढ़ती भूमिका क्या हो सकती है।

बग की प्रकृति

  • T: 'static और Drop के आसपास borrow checker में unsoundness।
  • न्यूनतम उदाहरण: एक generic struct Q<T: 'static>(Option<T>) जिसमें Drop impl भी 'static से bounded है।
  • कंपाइलर गलती से एक non‑'static reference (जैसे stack lifetime वाला &l) को Q में रखने देता है, जबकि Q में केवल 'static data होना चाहिए।
  • destructor फिर इसे 'static मान सकता है, उदाहरण के लिए इसे global में stash कर सकता है, जिससे use-after-free संभव हो जाता है।

यह क्यों अनदेखा रह गया

  • इसे trigger करने वाला pattern असामान्य माना जाता है: इसके लिए एक custom Drop और lifetime bounds का खास संयोजन चाहिए।
  • इस पर बहस है कि custom Drop कितना “normal” है: कुछ इसे दुर्लभ कहते हैं, कुछ इसे आम मानते हैं, खासकर FFI में; लेकिन यह exact pattern दुर्लभ है।
  • कई invalid lifetime programs स्पष्ट रूप से crash नहीं करते, इसलिए बग बिना साफ़ failure के भी exercised हो सकता है।

Safety guarantees, soundness, और UB

  • स्पष्टता:
    • Unsoundness = safe Rust में compiler/typechecker bugs के कारण UB हो सकता है।
    • Spec में UB = user well-defined behavior की सीमा से बाहर जाता है।
  • यह bug compiler में है, Rust के intended lifetime rules में नहीं; fix ऐसा code reject करना है।
  • कुछ लोग note करते हैं कि many open unsoundness issues हैं; दूसरे stress करते हैं कि fixes patch releases में भी ship हो सकते हैं, और affected code कभी “valid Rust” था ही नहीं।

C और अन्य languages से तुलना

  • कुछ लोग इसे Rust की safety marketing को overstated या false sense of security देने वाला मानते हैं।
  • दूसरे जवाब देते हैं कि C/C++ में भी compiler bugs होते हैं और साथ ही language-level UB बहुत व्यापक है, इसलिए Rust फिर भी safety में बड़ा सुधार है।
  • चर्चा है कि कोई भी language पूरी तरह safe नहीं हो सकती; लक्ष्य bugs की classes को impossible या बेहद rare बनाना है।

Formal methods और AI

  • Rust या उसके subsets को formally specify/prove करने के ongoing efforts के संदर्भ।
  • यह स्वीकार किया गया कि proof assistants, specs, और underlying math भी गलत हो सकते हैं, इसलिए absolute guarantees असंभव हैं।
  • कुछ लोग AI/LLMs को ऐसे bugs के लिए compilers को fuzz/search करने का promising tool मानते हैं; दूसरे skeptical हैं या AI hype से थके हुए हैं।

Community और social dynamics

  • Rust evangelism और दूसरे languages की आलोचना को लेकर शिकायतें, और साथ ही defenses कि official messaging अधिक measured है।
  • individual bugs पर overreaction को लेकर meta-discussion: कुछ लोग perspective की मांग करते हैं—यह एक वास्तविक लेकिन सीमित defect है, Rust के model की wholesale failure नहीं।