सभी C कोड को Rust में बदलने की तकनीक, TRACTOR

• DARPA का TRACTOR एक research program है जिसका उद्देश्य legacy C code को Rust में automatically बदलकर C programs में memory safety vulnerabilities की पूरी category को खत्म करना है
• C और C++ की memory safety समस्याओं पर 20 साल से अधिक समय से काम हो रहा है, लेकिन यह समझ बन चुकी है कि सिर्फ bug detection tools पर्याप्त नहीं हैं
• विकल्प यह है कि मौजूदा code को ऐसी safe programming language में ले जाया जाए जो compile time पर unsafe programs को reject कर सके
• conversion का परिणाम ऐसे quality और style को लक्ष्य बनाता है जैसा किसी skilled Rust developer द्वारा लिखे गए code में होता है, और static व dynamic analysis को large language model आधारित machine learning के साथ जोड़ता है
• MIT Lincoln Laboratory testing और evaluation संभाल रहा है, और benchmarks, milestone projects व tools public page पर publish किए गए हैं

---

TRACTOR का लक्ष्य

• TRACTOR “Translating All C to Rust” program है, जिसका लक्ष्य legacy C code को Rust में automatically convert करना है
• security के लिहाज से यह C programs में मौजूद memory safety security vulnerabilities की पूरी category को हटाना चाहता है
• converted code का लक्ष्य सिर्फ काम कर जाना नहीं, बल्कि ऐसा quality और style पाना है जैसा किसी skilled Rust developer द्वारा बनाए गए code में होता है

Rust conversion की जरूरत क्यों है

• C और C++ की memory safety समस्याएं software engineering community के लिए 20 साल से अधिक समय से एक चुनौती रही हैं
• यह सहमति बन चुकी है कि केवल bug detection tools पर निर्भर रहने से समस्या को पर्याप्त रूप से हल करना कठिन है
• अधिक पसंदीदा approach ऐसी safe programming language का उपयोग करना है जो compile time पर unsafe programs को reject कर सके
• TRACTOR इस target language के रूप में Rust का उपयोग करता है

automatic conversion में इस्तेमाल होने वाली तकनीकें

• TRACTOR legacy C code को Rust में ले जाने के लिए कई software analysis techniques और machine learning techniques को जोड़ता है

• analysis techniques

  • static analysis और dynamic analysis दोनों का उपयोग किया जाता है
  • large language models सहित machine learning techniques भी इस combination में शामिल हैं
  • यह combination C code की structure और behavior को समझने, और उसे Rust code में automatically convert करने के लिए जरूरी core तकनीकी आधार है

testing, evaluation और public resources

• MIT Lincoln Laboratory team research program की testing और evaluation करती है
• benchmarks, milestone projects और tools MIT Lincoln Laboratory TRACTOR page पर publish किए गए हैं
• संबंधित content के रूप में Eliminating Memory Safety Vulnerabilities Once and For All जुड़ा हुआ है

[GN⁺]

Hacker News की राय

• संदर्भ के लिए https://sam.gov/opp/1e45d648886b4e9ca91890285af77eb7/view भी देखने लायक है

  • प्रस्तावक ब्रीफिंग जानकारी PDF का सीधा लिंक: https://sam.gov/api/prod/opps/v3/opportunities/resources/fil...
    इसमें कहा गया है कि इस कार्यक्रम का उद्देश्य TRACTOR के तकनीकी लक्ष्य और चुनौतियाँ समझाना, संभावित प्रस्तावकों के सवालों के जवाब देना, और यह परखने का अवसर देना है कि उनका शोध TRACTOR प्रोग्राम के लक्ष्यों से कैसे मेल खा सकता है

• यह वाकई बहुत कठिन लगता है। खासकर इसलिए कि अनुभवी लोगों द्वारा लिखा गया idiomatic Rust C जैसा बिल्कुल नहीं दिखता, और दिलचस्प कोड का बड़ा हिस्सा C++ में लिखा होता है
  आखिरकार यह कुछ ऐसा ही नहीं है जैसे C प्रोग्राम में हर allocation lifetime का static निर्धारण करना? इसमें user-defined allocators या proprietary libraries में जाने वाली allocations भी शामिल हैं। इस क्षेत्र में लंबे समय से शोध हुआ है, लेकिन बहुत बड़ी सफलताएँ कम रही हैं, और C/C++ प्रोग्राम बिना reference counting जैसे safety mechanisms के भी इस तरह लिखे जा सकते हैं कि allocation lifetime इस बात से बँध जाए कि यूज़र कौन-सा बटन दबाता है। यह अच्छा विचार नहीं है, लेकिन संभव है
  एक और साफ समस्या यह है कि विश्लेषण के लिए दिया गया प्रोग्राम परिभाषा के अनुसार buggy code है। अगर lifetime सही मायने में समझ में आ रही होती, तो memory safety vulnerability भी नहीं होती और इसे बदलने की ज़रूरत भी नहीं पड़ती। static रूप से “lifetime कैसी होनी चाहिए” पता करने वाले शोध आम तौर पर यह मानते हैं कि जिस कोड का विश्लेषण किया जा रहा है वह शुरू से सही है। हाँ, ऐसा प्रोग्राम बनाने का लक्ष्य रखा जा सकता है जो उन जगहों की पहचान करे जहाँ lifetime तय नहीं हो पा रही और फिर डेवलपर से मदद माँगे

  • यह बहुत कठिन काम है, और DARPA को कठिन कामों पर पैसा लगाना पसंद है[1]
    लेकिन DARPA के लिए automatic program translation या Rust में automatic translation की यह पहली कोशिश नहीं है[2]
    [1]: https://www.urbandictionary.com/define.php?term=DARPA%20hard
    [2]: https://c2rust.com/
  • कठिन कामों की बात चली है तो DOE भी 20 साल से ज़्यादा समय से चल रहे ROSE नाम के एक प्रोजेक्ट को फंड कर रहा है। यह static analysis और C/C++/Cuda के बीच automatic translation के साथ-साथ Python जैसी high-level languages और HPC के लिए C/C++ variants भी संभालता है
    इस प्रोजेक्ट में एक unified abstract syntax tree है, जो इन भाषाओं को लगभग एक ही node type set के साथ सपोर्ट करता है, इसलिए यह काफ़ी शानदार है। 2014 की गर्मियों में Livermore internship के दौरान मुझे इस पर काम करने का मौका मिला था
    यह open source भी है: http://rosecompiler.org/ROSE_HTML_Reference/index.html
  • सामान्य स्थिति में यह शायद unsafe Rust में translate होगा, और कभी-कभी केवल अलग-थलग terminal nodes ही safe Rust में translate हो पाएँगे
    अगर सिर्फ borrow checker से जूझना ही कठिन लगता है, तो C के सभी संभावित प्रोग्राम स्पेस और उसके कुख्यात undefined behavior को ध्यान में रखते हुए उसे ऐसे कोड में automatically translate करना जिसे borrow checker मंज़ूर कर दे, उससे कहीं ज़्यादा कठिन है। compiler writing की पुरानी समस्याओं में से एक यह है that valid programs का space, compilable programs के space से बहुत बड़ा होता है
    जल्दी से खोजने पर c2rust जैसी कोशिशें भी दिखती हैं[1]। TRACTOR उनसे कैसे अलग है, यह जानने की जिज्ञासा है
    [1] https://github.com/immunant/c2rust
  • DARPA के प्रोजेक्ट्स को DARPA-hard यूँ ही नहीं कहा जाता
  • तरीका शायद कुछ ऐसा होगा: “AI प्रोग्राम की functionality को किसी technical language में summarize करे, फिर उसी feature set को cover करने वाला Rust code synthesize करे”
    अगर source program देने के बजाय उसका manual दिया जाए तो यह और दिलचस्प लगेगा। लेकिन manuals में प्रोग्राम के हर सूक्ष्म behavior का पूरा विवरण कम ही मिलता है, इसलिए कम-से-कम असली ground truth पाने के लिए source code देखना ज़रूरी पड़ सकता है

• इस प्रस्तावित पहल के बारे में कुछ समय से पता था, और अब इसका सार्वजनिक होना दिलचस्प है। यह बहुत महत्वाकांक्षी प्रस्ताव है, और इस स्तर की महत्वाकांक्षा DARPA के मिशन के अनुरूप लगती है, इसलिए उम्मीद है कि यह सफल हो।
  इस क्षेत्र में Rust के पक्षधर के रूप में, मैं C से Rust में स्वचालित अनुवाद की संभावना को लेकर इस प्रस्ताव को आगे बढ़ाने वालों की अपेक्षाएँ कम करने की कोशिश करता रहा हूँ। मेरे हिसाब से मूल बाधा यह है कि C source code, Rust source code की तुलना में कम जानकारी रखता है। C code को Rust code में बदलने के लिए किसी व्यक्ति या किसी चीज़ को वह गायब जानकारी बनानी पड़ेगी। जैसे किसी image को बहुत बड़ा कर देने से मूल image में कैप्चर न हुई information bits को बिना गलती के पैदा नहीं किया जा सकता, उसी कारण यह आसानी से साबित किया जा सकता है कि इस गायब जानकारी को पूरी तरह उत्पन्न करना असंभव है। अंततः मौजूदा source code में जो जानकारी नहीं है, उसका extrapolation, यानी कुछ हद तक invention, करना पड़ेगा। सही extrapolation के लिए judgment चाहिए, और यह एक ऐसी प्रक्रिया है जिसमें खासकर बिना supervision वाले language model जब बड़े पैमाने पर काम करेंगे, तो गलतियाँ होना तय है। मुझे लगता है कि इस समस्या को कुछ हद तक कम करने वाले समाधान प्रस्तावित किए जा सकते हैं, लेकिन मैं यहाँ विस्तार में नहीं जाऊँगा।
  अंत में, मुझे लगता है कि यह project कुछ स्तर की सफलता हासिल कर सकता है, लेकिन इसे सावधान और संयमित अपेक्षाओं के साथ आगे बढ़ाया जाना चाहिए। साथ ही, यह भी संभव है कि इससे कोई सार्वजनिक परिणाम बिल्कुल न निकले, इसलिए इस चरण पर इसका ज़रूरत से ज़्यादा अर्थ नहीं निकालना चाहिए। खासकर सरकार कोई एकसमान इकाई नहीं है, इसलिए इस project को C के पूर्ण खंडन या Rust के पूर्ण आशीर्वाद के रूप में नहीं देखना चाहिए। हर agency memory safety तकनीकों को अपनाने की दिशा और समय-सारिणी खुद तय करेगी। उदाहरण के लिए NIST, सिर्फ Rust ही नहीं बल्कि Ada SPARK, और कई hardened C/C++ dialects की भी सिफारिश करता है

  • Grammatech के CRAM प्रयास से इसका क्या संबंध है?
    https://cpp-rust-assisted-migration.gitlab.io/blog/
  • अगर C code के formal semantics को बचाए रखने की कोशिश न की जाए, और अनुवाद के बाद सिर्फ test suite पास होना ही पर्याप्त माना जाए, तो अनुवाद के लिए कहीं ज़्यादा गुंजाइश बनती है।
    वास्तविक Rustification projects अक्सर इसी तरह चलते हैं। Fuzzer भी अतिरिक्त test data बनाकर branch coverage बढ़ाने में मदद कर सकते हैं

• व्यक्तिगत रूप से, मुझे “दुनिया की हर चीज़ को Rust में फिर से लिखो” वाली सोच पसंद नहीं है। फिर भी, अगर आप किसी project को नई language या platform पर port करना चाहते हैं, तो mechanical translation एक खराब तरीका है।
  समय लगाकर बेहतर architecture की योजना बनानी चाहिए और बेहतर software system design करना चाहिए, फिर उसे टुकड़ों-टुकड़ों में बदलने का तरीका ढूँढना चाहिए। हवा में महल बनाओगे तो वह कभी ज़मीन तक नहीं पहुँचेगा। अगर इस system में Rust इस्तेमाल करने का फैसला किया है तो ठीक है, लेकिन उसे Rust की तरह इस्तेमाल करना चाहिए। C को Rust में ज्यों-का-त्यों ढोने की कोशिश नहीं करनी चाहिए।
  इससे कहीं बेहतर और परिपक्व प्रक्रिया यह होगी कि C को modern C में अपडेट किया जाए, और CBMC जैसे model checker से memory, resource, और integer operation safety को verify किया जाए। इससे codebase, knowledge base, और developers को बनाए रखते हुए, gradual Rust rewrite जैसी सुरक्षा मिल सकती है

  • संभावना नहीं है। CBMC शानदार है, लेकिन क्या आपने कभी “वास्तविक” program का formal verification किया है?
    मैं इस बात से सहमत हूँ कि हाथ से architecture design किए गए Rust version से replacement करना स्पष्ट रूप से बेहतर समाधान है, लेकिन उसकी लागत भी ज़्यादा है। यहाँ लक्ष्य शायद RLBox-शैली का ऐसा उत्पाद लगता है जो “लगभग बिना मेहनत के सुरक्षा में बड़ा सुधार” दे। अगर संसाधन हों तो इसका मतलब यह नहीं कि पूरी तरह manual rewrite नहीं करनी चाहिए, लेकिन कुछ न करने से तो यह बेहतर है
  • modern C में भी arrays और strings के मामले में वही security vulnerabilities हैं जो पारंपरिक C में थीं, और 50 साल में इसमें कुछ नहीं बदला है
  • यह legacy systems से बाहर निकलने के दौरान काम आ सकने वाला, निश्चित ही बड़ा और जोखिम भरा DARPA challenge है। लेकिन अगर आप किसी एक language के function या method को ChatGPT में डालकर दूसरी language में translate करने को कहें, तो वह आम तौर पर अच्छा काम नहीं करता।
    अगर आप उससे पहले उस समस्या के बारे में पूछें जिसे वह हल करने की कोशिश कर रहा है, तो वह कुछ अधिक बार सही हो सकता है, लेकिन तब भी आम तौर पर अच्छा नहीं करता। उसके output में आई बुनियादी चीज़ों को भी काम करने लायक बनाने के लिए अभी भी बहुत polishing और सोच-विचार चाहिए
  • अगर कोई dormant code हर जगह चल रहा हो लेकिन कोई उसे छूता न हो, तो “फिर से हाथ लगाने से पहले उसे घटिया Rust में translate कर देना” वाली बात में कुछ हद तक आकर्षण है।
    यह उस तरह का आकर्षण नहीं है जिसे साफ तौर पर अच्छा विचार कहा जाए। translation से बना “घटिया Rust”, bug नाम की background noise वाले C की तुलना में काम करने के लिए कहीं बदतर साबित हो सकता है। faithful translation की वजह से वे bugs उसी “घटिया Rust” में भी मौजूद रहेंगे। C में लोग किसी हद तक जानते हैं कि इन समस्याओं से कैसे निपटना है, लेकिन “घटिया Rust” सचमुच घटिया है क्योंकि Rust वाले लोग आम तौर पर ऐसी चीज़ों के आदी नहीं होते।
    फिर भी, यह संभावना शून्य नहीं है कि कोई व्यक्ति इसे बार-बार साफ करके सहनीय स्थिति तक लाने की तकनीकें विकसित कर ले। और project के non-goal output के रूप में “x, y, z की वजह से इसे सहनीय Rust में translate नहीं किया जा सकता” जैसी linter feedback भी निकल सकती है। C developers इसे देखकर सुधार कर सकते हैं, और अगर code अच्छे Rust में translate होने लायक बन गया, तो शायद उसे translate करने की ज़रूरत ही कम रह जाए।
    अगर ऐसा नतीजा निकले, तो कुछ लोगों के लिए executable C में समाधान लिखना और “translator/linter” को उन्हें गैर-टूटी हुई दिशा में ले जाने देना आसान हो सकता है। मुझे लगता है कि ऐसे सकारात्मक परिणामों की संभावना काफी कम है, लेकिन कभी-कभी dark horse bet लगाना ही शायद DARPA की job description के ज्यादा करीब है
  • “दुनिया की हर चीज़ को Rust में फिर से लिखो” वाली सोच कहीं भी नहीं है। बहुत सारा software ऐसा है जिसे dynamic languages में या Go जैसी garbage-collected statically typed languages में छोड़ देना कहीं बेहतर है। अच्छे engineers समझते हैं कि काम के हिसाब से सही tool चुनना चाहिए।
    असली बात यह है कि हमें उन memory safety CVE को कम करना शुरू करना चाहिए जो वास्तव में बार-बार समस्या साबित हो चुके हैं।
    मैं इस बात से सहमत हूँ कि अगर C/C++ से Rust में स्वचालित और भरोसेमंद अनुवाद संभव होता, तो अब तक हो चुका होता। लेकिन बेहतर architecture और systems की योजना बनाकर उन्हें टुकड़ों-टुकड़ों में बदलने की प्रक्रिया के बीच कहीं लोग यह आत्मविश्वास हासिल कर सकते हैं कि “अब हम C को काफी बेहतर तरीके से इस्तेमाल कर रहे हैं, तो शायद memory safety bugs अब नहीं बनाएँगे, क्या यहीं रुक नहीं जाना चाहिए?” और वास्तव में वे ऐसा करेंगे। फिर 6 महीने बाद एक और विडंबनापूर्ण buffer overflow CVE निकल आएगा।
    C को modern C में अपडेट करना और CBMC से verify करना भी बहुत बड़ा निवेश है। अगर इतना ही करना है, तो बेहतर है सीधे Rust पर जाएँ। यह कहना कि इससे gradual Rust rewrite जैसी ही सुरक्षा मिल जाएगी, संभव तो हो सकता है, लेकिन यह काफी अनिश्चित लगता है और किसी स्पष्ट निष्कर्ष से दूर है

• बहुत से लोग इसे सभी C और C++ कोड को Rust में अनुवाद करने की मांग या आदेश की तरह पढ़ रहे हैं, लेकिन आकर्षक प्रोजेक्ट नाम के बावजूद abstract को ऐसा नहीं पढ़ा जाना चाहिए। उसमें आपस में जुड़े हुए, लेकिन अलग-अलग दो पैराग्राफ हैं
  पहला, C और C++ बड़े पैमाने पर पर्याप्त रूप से सुरक्षित नहीं हैं। सावधानी से programming करने और अच्छे tools इस्तेमाल करने पर भी, मूल रूप से unsafe design की वजह से बहुत ज़्यादा vulnerabilities पैदा होती हैं। इसलिए जितना संभव हो उतना कोड “safe” भाषाओं में, खासकर memory safety की गारंटी देने वाली भाषाओं में, अनुवादित या नया लिखना चाहिए
  दूसरा, मौजूदा C कोड को Rust में अनुवाद करने वाले software के लिए funding और proposals आमंत्रित किए जा रहे हैं
  यह दुनिया को Rust में फिर से लिखने पर सहमति नहीं है। safe language में migration पर सहमति है, और Rust उसके उदाहरणों में से एक है, तथा इसका मतलब यह है कि इस migration में Rust को target करने वाला एक program मौजूद है

  • अगर उन भाषाओं में unsafe syntax है, तो उसे इस्तेमाल करने के नियम क्या होंगे? अगर यहाँ लागू करने के लिए defined rules का कोई set नहीं है, तो अंततः हम फिर वहीं पहुँच जाएंगे जहाँ से शुरू किया था
    Rust में safe mode है। Rust खुद safe language नहीं है। दिलचस्प काम करने के लिए unsafe blocks की ज़रूरत पड़ती है। इससे बहुत कुछ हासिल नहीं होता
    दूसरी ओर, बहुत-सी garbage-collected भाषाएँ हैं जिनमें programmers को pointers छूने तक नहीं दिए जाते। फिर उन भाषाओं पर विचार क्यों नहीं किया जाता? वजह है performance। Rust programmers performance को इतना “महत्व” देते हैं कि उस भाषा से मूल समस्या कभी हल नहीं की जा सकती
    performance चाहिए, या safety चाहिए? दोनों एक साथ नहीं मिल सकते

• यह सचमुच हैरान करने वाली बात है कि यह किसी भी automated तरीके से काम कर सकता है। किसी सामान्य C program को Rust में line-by-line transcribe नहीं किया जा सकता
  C programs में pointers और aliasing हर जगह होते हैं, और Rust ऐसे concepts को साफ़ तौर पर रोकता है। पूरे को unsafe में लपेटे बिना, C program को Rust में फिर से लिखने के लिए बहुत-सी सामान्य संरचनाओं पर ऊँचे स्तर से दोबारा सोचना पड़ेगा

  • line-by-line translation असंभव है, इसलिए बड़े semantic reasoning के लिए AI की ज़रूरत होगी
    सब कुछ एक ही बार में translate करने की भी ज़रूरत नहीं है। Rust compiler की एक बड़ी value यह है कि वह बहुत-सी concrete जानकारी देता है, जिसे वापस LLM में डालकर iterate किया जा सकता है
    मेरे startup grit.io में हम इसी तरह की समस्या पर काम कर चुके हैं, और मुझे लगता है कि C -> Rust निकट भविष्य में पर्याप्त रूप से संभाला जा सकेगा। यह निश्चित रूप से आसान नहीं है, लेकिन हल करने योग्य समस्या है
  • multi-threaded programs को छोड़ दें, तो क्या long-term aliasing वास्तव में पूरे C program में हर जगह होता है? मुझे लगता है कि बहुत से programs में इसका ज़्यादातर हिस्सा एक ही function scope के अंदर, या उसके अंदर होने वाले function calls के पार होगा। उस स्थिति में क्या borrowing से काम नहीं चल सकता?
    अगर ऐसा है, तो इसे एक sub-problem की तरह लिया जा सकता है, और threads के बीच data कैसे share हो रहा है, उसे detect करना दूसरी problem हो सकती है। बाद वाले मामले में बहुत-से programs में ऐसे implicit ownership rules होंगे जैसे “thread T1 queue Q में डालता है, और thread T2 उसे निकालता है”। इसे “queue में डालने पर ownership transfer हो जाती है” में translate किया जा सकता है
    ऐसे rules detect करना आसान नहीं होगा, लेकिन यह पूरी तरह पहुँच से बाहर का काम भी नहीं लगता, और research project के रूप में पर्याप्त अर्थपूर्ण हो सकता है
  • एक भोले beginner के नज़रिए से पूछूँ तो, क्या line-by-line जाते हुए पूरे program को unsafe में wrap करके, उसी binary में compile करके, equivalence को लगातार verify करते हुए धीरे-धीरे unsafe हटाया नहीं जा सकता?
    ऐसा करने पर कम-से-कम जितना संभव हो उतना Rust में लाया जा सकता है, और जिन concepts पर engineers को दोबारा सोचना पड़े, उन्हें अलग से संभाला जा सकता है
  • line-by-line translation के लिए बहुत ज़्यादा “AI” की भी ज़रूरत नहीं होगी। एक मोटा-मोटा, ज्यादातर unsafe वाला Rust translation बन सकता है
    मेरा मानना है कि AI को सच में उपयोगी और valid program बनाने के लिए lifetimes वगैरह समझनी होंगी। अगर वह सचमुच ऐसा कर ले, तो वह प्रभावशाली होगा
  • खासकर उन codebases में यह कैसे काम करेगा, यह जानने की उत्सुकता है जो macros का बहुत इस्तेमाल करते हैं

• अगर आप बहुत सख्त coding practices अपनाएँ, और code में ढेर सारी proprietary annotations मांगने वाले third-party static verification tools integrate करें, तो C/C++ में भी कुछ वैसा ही परिणाम पाया जा सकता है
  या फिर बस Rust इस्तेमाल कर लें

  • C/C++ community को Rust के खिलाफ प्रतिक्रिया करते देखना काफ़ी मज़ेदार है। उन भाषाओं के साथ बिताए दशकों की मेहनत और अनुभव ने स्पष्ट रूप से उनकी reasoning circuitry को overwrite कर दिया है
    जब एक वास्तविक alternative मौजूद है, तो इतनी बड़ी और इतनी स्पष्ट design flaws वाली languages का बचाव कोई होश में रहकर कैसे कर सकता है
  • मेरा मतलब “proprietary situation” नहीं, बल्कि proprietary annotations था। phone autocomplete की वजह से ऐसा लिख गया

• यह सफल होता नहीं दिखता। C में ऐसी abstractions हैं जिन्हें Rust में बड़े बदलावों के बिना reproduce नहीं किया जा सकता
  C में यह आम बात है कि एक ही pointer को रखने वाली दो अलग data structures उसी pointer पर write करें। Rust में इसे trivially reproduce नहीं किया जा सकता, और इसके लिए काफ़ी चतुर हस्तक्षेप चाहिए

  • शायद ऐसा कुछ बनाया जा सकता है जो compile हो जाए और “Rust” भी हो और “AI” भी। buzzword requirements भी दोगुनी पूरी हो जाएँगी, इसलिए research project को justify करना भी आसान होगा
    लेकिन इससे कम bugs वाला output, या वह program structure जो Rust की reliability बनाता है, अपने-आप उत्पन्न होने वाली कोई प्रक्रिया नहीं मिलेगी

• क्या इसका automated होना ज़रूरी है? अगर हाँ, तो क्या C को Rust में automatically port करने वाला कोई program अनिवार्य रूप से C code को खुद सुरक्षित बनाने की सारी क्षमता भी अपने भीतर नहीं रखेगा?

  • उस वाक्य को समझदारी से पढ़ें तो यह ज़रूरी नहीं कि fully automated ही मतलब हो, और उस स्थिति में सवाल का जवाब नहीं है
    कुछ C code ऐसा होता है जो सिर्फ “correctness verify नहीं की जा सकती” वाली स्थिति में नहीं होता, बल्कि “memory safety के लिहाज़ से वास्तव में गलत” होता है। ऐसे code का बिना इंसानी दखल के automatic translation नहीं होगा। जब सही equivalent code ही मौजूद नहीं है, तो वह कैसे संभव होगा। tool में ऐसा escape hatch होना चाहिए जो कह सके, “मुझे नहीं पता यह code क्या करना चाहता है, और यह जो वास्तव में कर रहा है वह compiler के साथ किए गए समझौते का उल्लंघन है, इसलिए मैं यह भी जानता हूँ कि यह intended behavior नहीं है। इंसान, मदद करो”
    सैद्धांतिक रूप से यह असंभव है कि उस escape hatch का इस्तेमाल केवल तब ही हो जब undefined behavior वास्तव में होता हो। Rice के theorem की वजह से। और व्यावहारिक रूप से भी, बहुत कठिन code को अंधाधुंध translate नहीं करना चाहिए, इसलिए ऐसा करने की कोशिश करना ही शायद वांछनीय नहीं है
    अंत में, मेरी कल्पना है कि tool ज़्यादातर काम करने वाला, लेकिन इंसान के मार्गदर्शन से चलने वाला interactive tool बनेगा। और उस इंसानी मार्गदर्शन के नतीजे में ठीक-ठीक equivalent code नहीं, बल्कि वही उद्देश्य पूरा करने वाला code निकलेगा

• अगर 1) Rust में memory bugs नहीं हैं और 2) C को Rust में अपने-आप translate किया जा सकता है, तो इसका मतलब होगा कि सभी memory bugs अपने-आप ठीक किए जा सकते हैं
  यह लगभग निश्चित रूप से सच नहीं है। सामान्य स्थिति में यह काम पूरी तरह असंभव होने की बहुत अधिक संभावना है

  • आपने यह स्पष्ट नहीं किया कि C कोड के सभी व्यवहारों को सुरक्षित रखना है, इसलिए इस समस्या का एक तुच्छ समाधान मौजूद है
    उदाहरण के लिए, सभी dynamic memory allocations को translation के समय तय किए गए fixed buffer से बदल दें, और उस buffer में फिट न होने वाले सभी inputs को अस्वीकार कर दें