नमस्कार, हेब्र! मैं आपके लिए लेख "क्या जंग असुरक्षित है?" का अनुवाद प्रस्तुत करता है। लेखक नोरा कोड्स।

मैंने कई गलतफहमियों को देखा है कि असुरक्षित भाषा का मतलब क्या है, "सुरक्षित सिस्टम प्रोग्रामिंग भाषा" के रूप में रस्ट भाषा की उपयोगिता और शुद्धता और इसके प्रचार के लिए। एक छोटे से ट्वीट में दुर्भाग्य से सच को और अधिक जटिल किया जा सकता है, दुर्भाग्य से। इस तरह मैं उसे देखता हूं।

सामान्य तौर पर, असुरक्षित कीवर्ड उस प्रकार के सिस्टम को बंद नहीं करता है जो रस्ट कोड को सही रखता है । यह केवल कुछ "सुपरपावर" का उपयोग करना संभव बनाता है, जैसे कि डेरेफेरिंग पॉइंटर्स। असुरक्षित का उपयोग मूल रूप से असुरक्षित दुनिया के आधार पर सुरक्षित अमूर्तता को लागू करने के लिए किया जाता है ताकि अधिकांश Rust कोड इन अमूर्त का उपयोग कर सकें और असुरक्षित मेमोरी एक्सेस से बच सकें।

सुरक्षा की गारंटी

जंग अपने मूल सिद्धांतों में से एक के रूप में सुरक्षा की गारंटी देता है। हम कह सकते हैं कि यह भाषा के अस्तित्व का अर्थ है । हालांकि, यह कार्यक्रम के निष्पादन और कचरा संग्रहकर्ता के उपयोग के दौरान पारंपरिक अर्थों में सुरक्षा प्रदान नहीं करता है। इसके बजाय, रूस्ट कब और किन मूल्यों तक पहुँचा जा सकता है, इस पर नज़र रखने के लिए एक बहुत ही उन्नत प्रकार की प्रणाली का उपयोग करता है। तब कंपाइलर प्रत्येक रस्ट प्रोग्राम का सांख्यिकीय रूप से विश्लेषण करता है ताकि यह सुनिश्चित हो सके कि यह हमेशा सही स्थिति में है।

अजगर सुरक्षा

आइए एक उदाहरण के रूप में अजगर को लें। शुद्ध पायथन कोड स्मृति को दूषित नहीं कर सकता है। सीमाओं से परे जाने के लिए सूची आइटम तक पहुंच की जांच है; लिंक द्वारा दिए गए लिंक लटकते लिंक की उपस्थिति से बचने के लिए गिने जाते हैं; पॉइंटर्स के साथ मनमाना अंकगणित करने का कोई तरीका नहीं है।

इसके दो परिणाम हैं। सबसे पहले, कई प्रकार "विशेष" होने चाहिए। उदाहरण के लिए, शुद्ध पायथन में एक प्रभावी सूची या शब्दकोश को लागू करना संभव नहीं है। इसके बजाय, सीपीथॉन दुभाषिया का उनका आंतरिक कार्यान्वयन है। दूसरे, बाहरी कार्यों (पायथन में लागू नहीं किए जाने वाले फ़ंक्शन), जिसे बाहरी फ़ंक्शन का इंटरफ़ेस कहा जाता है, को एक विशेष ctypes मॉड्यूल के उपयोग की आवश्यकता होती है और भाषा की सुरक्षा गारंटी का उल्लंघन करता है।

एक अर्थ में, इसका मतलब है कि पायथन में लिखी गई सभी चीजें स्मृति तक सुरक्षित पहुंच की गारंटी नहीं देती हैं।

जंग में सुरक्षा

जंग सुरक्षा भी प्रदान करती है, लेकिन सी में असुरक्षित संरचनाओं को लागू करने के बजाय, यह एक चाल प्रदान करता है: असुरक्षित कीवर्ड। इसका अर्थ है कि Rust में मूलभूत डेटा संरचनाएं जैसे Vec, VecDeque, BTreeMap और String, Rust में कार्यान्वित की जाती हैं।

आप पूछ सकते हैं: "लेकिन, अगर रुस्ट अपने कोड सुरक्षा की गारंटी के खिलाफ एक चाल प्रदान करता है, और इस चाल का उपयोग करके मानक पुस्तकालय को लागू किया जाता है, तो क्या Rust में सब कुछ असुरक्षित नहीं माना जाएगा?"

एक शब्द में, प्रिय पाठक, हां , ठीक उसी तरह जिस तरह यह पायथन में था। आइए इसे और अधिक विस्तार से देखें।

सुरक्षित जंग में क्या मना है?

जंग में सुरक्षा अच्छी तरह से परिभाषित है: हम इसके बारे में बहुत सोचते हैं। संक्षेप में, सुरक्षित जंग कार्यक्रम नहीं कर सकते हैं:

• एक पॉइंटर को डीफेर करना जो कि कंपाइलर की तुलना में एक अलग प्रकार की ओर इशारा करता है । इसका मतलब यह है कि अशक्त करने के लिए कोई संकेत नहीं हैं (क्योंकि वे कहीं भी इंगित नहीं करते हैं), सीमाओं और / या विभाजन त्रुटियों (विभाजन दोष) से ​​बाहर जाने की कोई त्रुटि नहीं, कोई बफर ओवरफ्लो नहीं। लेकिन इसका मतलब यह भी है कि मेमोरी को फ्रीज करने या मेमोरी को फिर से फ्री करने के बाद कोई उपयोग नहीं होता है (क्योंकि मेमोरी को फ्रीज करने को पॉइंटर को डीरेफेरेंस करने के लिए माना जाता है) और टाइपिंग के लिए कोई दंड नहीं है ।
• किसी वस्तु पर एक साथ कई परस्पर संदर्भ या किसी वस्तु में परस्पर परिवर्तनशील और अपरिवर्तनीय संदर्भ रखें । यही है, यदि आपके पास किसी वस्तु का एक परस्पर संदर्भ है, तो आपके पास केवल यह हो सकता है, और यदि आपके पास ऑब्जेक्ट के लिए एक अपरिवर्तनीय संदर्भ है, तो यह तब तक नहीं बदलेगा जब तक आप इसे नहीं रखते। इसका मतलब यह है कि आप सुरक्षित जंग में एक डेटा दौड़ को बाध्य नहीं कर सकते हैं, जो एक गारंटी है कि अधिकांश अन्य सुरक्षित भाषाएं प्रदान नहीं कर सकती हैं।

Rust इस जानकारी को एक प्रकार की प्रणाली में या बीजीय डेटा प्रकारों का उपयोग करके एन्कोड करता है, जैसे कि मान / अनुपस्थिति के अस्तित्व / अनुपस्थिति को इंगित करने के लिए विकल्प / परिणाम <T, E> त्रुटि / सफलता, या संदर्भ और उनके जीवनकाल को इंगित करने के लिए, उदाहरण के लिए, और T & mut T को इंगित करने के लिए। एक आम (अपरिवर्तनीय) लिंक और एक एक्सक्लूसिव (म्यूटेबल) लिंक और 'एक टी बनाम और' बी टी, अलग-अलग संदर्भों में सही होने वाले लिंक को अलग करने के लिए (यह आमतौर पर छोड़े जाते हैं क्योंकि कंपाइलर अपने आप को पता लगाने के लिए पर्याप्त स्मार्ट है) ।

उदाहरण

उदाहरण के लिए, निम्न कोड संकलित नहीं होगा क्योंकि इसमें एक लटकता हुआ लिंक होता है। अधिक विशेष रूप से, my_struct पर्याप्त नहीं रहता है । दूसरे शब्दों में, फ़ंक्शन किसी ऐसी चीज़ का लिंक लौटाएगा जो अब मौजूद नहीं है, और इसलिए कंपाइलर (और, वास्तव में, यह भी नहीं जानता कि कैसे) इसे संकलित कर सकता है।

fn dangling_reference(v: &u64) -> &MyStruct { //     MyStruct   ,  v,   . let my_struct = MyStruct { value: v }; //      my_struct. return &my_struct; //  - my_struct  (  ). } 

यह कोड ऐसा ही करता है, लेकिन यह मान को ढेर पर रखकर काम करने की कोशिश करता है (बॉक्स रस्ट में बेस स्मार्ट पॉइंटर का नाम है)।

 fn dangling_heap_reference(v: &u64) -> &Box<MyStruct> { let my_struct = MyStruct { value: v }; //    Box         . let my_box = Box::new(my_struct); //      my_box. return &my_box; // my_box   .   "" my_struct       - , //    - MyStruct  . } 

सही कोड बॉक्स के द्वारा खुद को उसके संदर्भ के बजाय लौटा दिया जाता है। यह स्वामित्व के हस्तांतरण को एन्कोड करता है - मेमोरी को मुक्त करने की जिम्मेदारी - फ़ंक्शन के हस्ताक्षर में। हस्ताक्षर को देखते समय, यह स्पष्ट हो जाता है कि कॉलिंग कोड बॉक्स के साथ क्या होता है, और वास्तव में, संकलक इसे स्वचालित रूप से संसाधित करता है।

 fn no_dangling_reference(v: &u64) -> Box<MyStruct> { let my_struct = MyStruct { value: v }; let my_box = Box::new(my_struct); //    my_box  . return my_box; //    .         , //    ;       //  Box<MyStruct>       ,      . } 

कुछ बुरी चीजें सुरक्षित जंग में मना नहीं हैं। उदाहरण के लिए, यह संकलक के दृष्टिकोण से अनुमत है:

• कार्यक्रम में गतिरोध का कारण
• स्मृति की एक बड़ी मात्रा में रिसाव
• फ़ाइल हैंडल, डेटाबेस कनेक्शन या मिसाइल शाफ्ट कवर को बंद करने में विफल

रस्ट इकोसिस्टम की ताकत यह है कि कई परियोजनाएं यह सुनिश्चित करने के लिए एक प्रकार की प्रणाली का उपयोग करने के लिए चुनती हैं कि कोड यथासंभव सटीक है, लेकिन संकलक को ऐसे ज़बरदस्ती की आवश्यकता नहीं है, सिवाय उन मामलों में जहां सुरक्षित मेमोरी एक्सेस प्रदान की जाती है।

असुरक्षित जंग में क्या अनुमति है?

असुरक्षित Rust कोड असुरक्षित कीवर्ड वाला Rust कोड है। असुरक्षित को किसी फ़ंक्शन या कोड के ब्लॉक पर लागू किया जा सकता है। जब किसी फ़ंक्शन पर लागू किया जाता है, तो इसका अर्थ है "इस फ़ंक्शन के लिए आवश्यक है कि कॉल कोड मैन्युअल रूप से उस इंवेलेरेंट को प्रदान करे जो आमतौर पर कंपाइलर द्वारा प्रदान किया जाता है।" जब कोड के एक ब्लॉक पर लागू किया जाता है, तो इसका मतलब है "कोड का यह ब्लॉक मैन्युअल रूप से अपरिवर्तनीय को स्मृति तक असुरक्षित पहुंच को रोकने के लिए आवश्यक प्रदान करता है, और इसलिए इसे असुरक्षित चीजों को करने की अनुमति है।"

दूसरे शब्दों में, फ़ंक्शन के लिए असुरक्षित का अर्थ है "आपको सब कुछ जांचने की आवश्यकता है", और कोड ब्लॉक पर - "मैंने पहले से ही सब कुछ जांच लिया है।"

जैसा कि द रूस्ट प्रोग्रामिंग लैंग्वेज में नोट किया गया है, असुरक्षित कीवर्ड के साथ चिह्नित ब्लॉक में कोड:

• एक पॉइंटर को डिरेल करें। यह एक प्रमुख "महाशक्ति" है जो आपको दोहरी लिंक की गई सूचियों, हैशमैप और अन्य मूलभूत डेटा संरचनाओं को लागू करने की अनुमति देता है।
• असुरक्षित फ़ंक्शन या विधि को कॉल करें। इसके बारे में और नीचे।
• एक स्थैतिक स्थिर चर को एक्सेस या संशोधित करें। स्थैतिक चर जिनके दायरे को नियंत्रित नहीं किया जाता है, उन्हें सांख्यिकीय रूप से जाँच नहीं किया जा सकता है, इसलिए उनका उपयोग असुरक्षित है।
• असुरक्षित विशेषता को लागू करें। असुरक्षित लक्षणों को ध्वजांकित करने के लिए उपयोग किया जाता है कि क्या विशेष प्रकार के कुछ अपरिवर्तनीयों की गारंटी देते हैं। उदाहरण के लिए, भेजें और सिंक यह निर्धारित करते हैं कि थ्रेड सीमाओं के बीच एक प्रकार भेजा जा सकता है या एक साथ कई थ्रेड द्वारा उपयोग किया जा सकता है।

ऊपर लटकने वाले बिंदुओं को याद रखें? असुरक्षित शब्द जोड़ें, और कंपाइलर दो बार शपथ लेगा क्योंकि वह असुरक्षित उपयोग करना पसंद नहीं करता है जहां इसकी आवश्यकता नहीं है।

इसके बजाय, असुरक्षित कीवर्ड का उपयोग मनमाने ढंग से पॉइंटर ऑपरेशन के आधार पर सुरक्षित सार को लागू करने के लिए किया जाता है। उदाहरण के लिए, वीईके प्रकार असुरक्षित का उपयोग करके कार्यान्वित किया जाता है, लेकिन इसका उपयोग करना सुरक्षित है, क्योंकि यह तत्वों तक पहुंचने के प्रयासों की जांच करता है और ओवरफ्लो की अनुमति नहीं देता है। यद्यपि यह सेट_लेन जैसे ऑपरेशन प्रदान करता है, जिससे असुरक्षित मेमोरी एक्सेस हो सकती है, उन्हें असुरक्षित के रूप में चिह्नित किया जाता है।

उदाहरण के लिए, हम no_dangling_reference उदाहरण में भी ऐसा ही कर सकते हैं, लेकिन असुरक्षित के अनुचित उपयोग के साथ:

 fn manual_heap_reference(v: u64) -> *mut MyStruct { let my_struct = MyStruct { value: v }; let my_box = Box::new(my_struct); //  Box    . let struct_pointer = Box::into_raw(my_box); return struct_pointer; //   ;     . // MyStruct     . } 

असुरक्षित शब्द की कमी पर ध्यान दें। पॉइंटर्स बनाना बिल्कुल सुरक्षित है। जैसा कि लिखा गया था, यह एक मेमोरी लीक का जोखिम है, लेकिन इससे ज्यादा कुछ नहीं है, और मेमोरी लीक सुरक्षित हैं। इस फ़ंक्शन को कॉल करना भी सुरक्षित है। असुरक्षित केवल तभी आवश्यक है जब कोई सूचक को निष्क्रिय करने की कोशिश करता है। एक अतिरिक्त बोनस के रूप में, dereferencing स्वचालित रूप से आवंटित मेमोरी जारी करेगा।

 fn main() { let my_pointer = manual_heap_reference(1337); let my_boxed_struct = unsafe { Box::from_raw(my_pointer) }; //  "Value: 1337" println!("Value: {}", my_boxed_struct.value); // my_boxed_struct    .       ,  //    - MyStruct } 

अनुकूलन के बाद, यह कोड केवल एक बॉक्स को वापस करने के बराबर है। बॉक्स एक सुरक्षित सूचक-आधारित अमूर्त है क्योंकि यह हर जगह बिंदुओं के वितरण को रोकता है। उदाहरण के लिए, मुख्य का अगला संस्करण एक दोहरी मुक्त मेमोरी (डबल-फ्री) का नेतृत्व करेगा ।

 fn main() { let my_pointer = manual_heap_reference(1337); let my_boxed_struct_1 = unsafe { Box::from_raw(my_pointer) }; // DOUBLE FREE BUG! let my_boxed_struct_2 = unsafe { Box::from_raw(my_pointer) }; //  "Value: 1337" . println!("Value: {}", my_boxed_struct_1.value); println!("Value: {}", my_boxed_struct_2.value); // my_boxed_struct_2    .     ,  //    - MyStruct. //  my_boxed_struct_1    .      , //      - MyStruct.  double-free bug. } 

तो सुरक्षित अमूर्तता क्या है?

सुरक्षित अमूर्तता एक अमूर्तता है जो एपीआई प्रदान करने के लिए एक प्रकार की प्रणाली का उपयोग करता है जिसका उपयोग उपरोक्त सुरक्षा गारंटी का उल्लंघन करने के लिए नहीं किया जा सकता है। बॉक्स सुरक्षित है * म्यूट टी, क्योंकि यह डबल मेमोरी डीललोकेशन को जन्म नहीं दे सकता है, जैसा कि ऊपर सचित्र है।

एक अन्य उदाहरण Rust में Rc प्रकार है। यह एक संदर्भ गिनती सूचक है - ढेर पर डेटा के लिए एक गैर-परिवर्तनशील संदर्भ। चूंकि यह मेमोरी के एक क्षेत्र में एक साथ कई एक्सेस की अनुमति देता है, इसलिए इसे सुरक्षित माना जाने के लिए परिवर्तन को रोकना चाहिए ।

इसके अतिरिक्त, यह थ्रेड सुरक्षित नहीं है। यदि आपको थ्रेड सुरक्षा की आवश्यकता है, तो आपको आर्क प्रकार (एटॉमिक रेफरेंस काउंटिंग) का उपयोग करना होगा, जिसमें लिंक काउंटिंग के लिए परमाणु मूल्यों के उपयोग और बहु-थ्रेडेड वातावरण में संभावित डेटा रेस को रोकने के कारण एक प्रदर्शन जुर्माना है।

संकलक आपको आरसी का उपयोग करने की अनुमति नहीं देगा जहां आपको आर्क का उपयोग करना चाहिए, क्योंकि आरसी जैसे रचनाकारों ने इसे थ्रेड सुरक्षित के रूप में चिह्नित नहीं किया है। अगर उन्होंने ऐसा किया, तो यह अनुचित होगा: सुरक्षा का झूठा वादा।

असुरक्षित जंग की आवश्यकता कब होती है?

असुरक्षित रस्ट हमेशा आवश्यक होता है जब एक ऑपरेशन करना आवश्यक होता है जो ऊपर वर्णित उन दो नियमों में से एक का उल्लंघन करता है। उदाहरण के लिए, एक दोहरी लिंक की गई सूची में, एक ही डेटा (अगले तत्व और पिछले तत्व के लिए) के लिए परस्पर लिंक की अनुपस्थिति पूरी तरह से लाभ से वंचित करती है। असुरक्षित के साथ, एक डबल लिंक की गई सूची कार्यान्वयनकर्ता * म्यूट नोड पॉइंटर्स का उपयोग करके कोड लिख सकता है और फिर इसे एक सुरक्षित अमूर्तता में संलग्न कर सकता है।

एक और उदाहरण एम्बेडेड सिस्टम के साथ काम कर रहा है। अक्सर माइक्रोकंट्रोलर रजिस्टरों के एक सेट का उपयोग करते हैं जिनके मूल्य डिवाइस की भौतिक स्थिति द्वारा निर्धारित किए जाते हैं। जब आप इस तरह के रजिस्टर से & u u म्यूट लेते हैं तो दुनिया रुक नहीं सकती है, इसलिए डिवाइस सपोर्ट क्रेट के साथ काम करने के लिए असुरक्षित होना आवश्यक है। आमतौर पर, ये बक्से पारदर्शी, सुरक्षित रैपरों में राज्य को घेर लेते हैं जो जब भी संभव हो डेटा की प्रतिलिपि बनाते हैं, या कंपाइलर गारंटी प्रदान करने वाली अन्य तकनीकों का उपयोग करते हैं।

कभी-कभी एक ऑपरेशन करना आवश्यक होता है जो एक साथ पढ़ने और लिखने या स्मृति तक असुरक्षित पहुंच का कारण बन सकता है, और यह वह जगह है जहां असुरक्षित की आवश्यकता होती है। लेकिन जब तक यह सुनिश्चित करने का अवसर है कि उपयोगकर्ता द्वारा किसी चीज़ को छूने से पहले सुरक्षित आक्रमणकारियों को बनाए रखा जाता है (यानी, असुरक्षित असुरक्षित), सब कुछ ठीक है।

यह जिम्मेदारी किसके कंधे पर है?

हम पहले दिए गए एक बयान पर आते हैं - हाँ , रस्ट कोड की उपयोगिता असुरक्षित कोड पर आधारित है। इस तथ्य के बावजूद कि यह पायथन में बुनियादी डेटा संरचनाओं के असुरक्षित कार्यान्वयन की तुलना में थोड़ा अलग तरीके से किया जाता है, वीईसी, हैशमप आदि के कार्यान्वयन को कुछ हद तक सूचक जोड़तोड़ का उपयोग करना चाहिए ।

हम कहते हैं कि जंग सुरक्षित है, इस आधारभूत धारणा के साथ कि असुरक्षित कोड जो हम अपनी निर्भरता के माध्यम से मानक पुस्तकालय या अन्य पुस्तकालयों के कोड के माध्यम से उपयोग करते हैं, सही ढंग से लिखा और समझाया जाता है। रस्ट का मौलिक लाभ यह है कि असुरक्षित कोड असुरक्षित ब्लॉकों में संचालित होता है जिन्हें उनके लेखकों द्वारा सावधानीपूर्वक जांचना चाहिए।

पायथन में, मेमोरी मैनिपुलेशन की सुरक्षा का भार केवल व्याख्याकारों और बाहरी कार्यों के इंटरफेस के उपयोगकर्ताओं के डेवलपर्स के पास है। सी में, यह बोझ हर प्रोग्रामर के साथ रहता है।

जंग में, यह असुरक्षित कीवर्ड के उपयोगकर्ताओं के साथ निहित है। यह स्पष्ट है, क्योंकि इस तरह के कोड के अंदर अदृश्य रूप से बनाए रखा जाना चाहिए, और इसलिए पुस्तकालय या एप्लिकेशन कोड में इस तरह की सबसे छोटी राशि के लिए प्रयास करना आवश्यक है। असुरक्षा का पता लगाया, उजागर और संकेत किया गया है। इसलिए, यदि आपके Rust कोड में segfaults होते हैं, तो आपको कंपाइलर में कोई त्रुटि मिलती है या आपके असुरक्षित कोड की कई लाइनों में त्रुटि होती है।

यह एक आदर्श प्रणाली नहीं है, लेकिन यदि आपको एक ही समय में गति, सुरक्षा और मल्टीथ्रेडिंग की आवश्यकता है, तो यह एकमात्र विकल्प है।