नल पॉइंटर
कम्प्यूटिंग में, नल पॉइंटर या नल संदर्भ यह प्रदर्शित करने के लिए सहेजा गया मान है कि पॉइंटर (कंप्यूटर प्रोग्रामिंग) या संदर्भ (कंप्यूटर विज्ञान) वैध ऑब्जेक्ट (कंप्यूटर विज्ञान) को संदर्भित नहीं करता है। प्रोग्राम नियमित रूप से अज्ञात लंबाई की सूची (कंप्यूटिंग) के अंत या कुछ कार्रवाई करने में विफलता जैसी स्थितियों का प्रतिनिधित्व करने के लिए नल पॉइंटर्स का उपयोग करते हैं; अशक्त पॉइंटरों के इस उपयोग की तुलना अशक्त प्रकारों और विकल्प प्रकार में कुछ भी नहीं मान से की जा सकती है।
अशक्त पॉइंटर को अप्रारंभीकृत चर के साथ भ्रमित नहीं किया जाना चाहिए: अशक्त पॉइंटर को किसी वैध वस्तु को प्रदर्शित करने वाले किसी भी पॉइंटर के साथ असमान तुलना करने का आश्वासन दिया जाता है। चूँकि, भाषा और कार्यान्वयन के आधार पर, अप्रारंभीकृत पॉइंटर के पास ऐसा कोई आश्वासन नहीं हो सकता है। इसकी तुलना अन्य, मान्य संकेतकों के समान हो सकती है; या इसकी तुलना नल पॉइंटरों के समान हो सकती है। यह भिन्न-भिन्न समय पर दोनों कार्य कर सकता है; या तुलना अपरिभाषित व्यवहार हो सकती है।
क्योंकि नल पॉइंटर किसी सार्थक वस्तु को प्रदर्शित नहीं करता है, उस (अमान्य) मेमोरी स्थान पर संग्रहीत डेटा तक पहुंचने का प्रयास रन-टाइम त्रुटि या तत्काल प्रोग्राम क्रैश का कारण बन सकता है। यह नल पॉइंटर त्रुटि है, यह सबसे सामान्य प्रकार की सॉफ़्टवेयर अशक्त में से है,[1] और इस अवधारणा को प्रस्तुत करने वाले टोनी होरे ने इसे अरब डॉलर की त्रुटि के रूप में संदर्भित किया है।
सी
सी (प्रोग्रामिंग भाषा) में, किसी भी प्रकार के दो नल पॉइंटर्स की तुलना समान होने का आश्वासन दिया जाता है।[2] प्रीप्रोसेसर मैक्रो NULL को <stdlib.h> में कार्यान्वयन-परिभाषित नल पॉइंटर स्थिरांक के रूप में परिभाषित किया गया है,[3] जिसे सी99 में पोर्टेबल रूप से ((void *)0) व्यक्त किया जा सकता है जिसका अर्थ है कि पूर्णांक मान 0 प्रकार में परिवर्तित हो जाता है void* (नल प्रकार का पॉइंटर)[4] सी मानक यह नहीं कहता है कि नल पॉइंटर मेमोरी एड्रेस 0 के पॉइंटर के समान है, चूँकि व्यवहार में ऐसा हो सकता है। नल पॉइंटर को असंदर्भित करना सी में अपरिभाषित व्यवहार है,[5]और अनुरूप कार्यान्वयन को यह मानने की अनुमति है कि कोई भी पॉइंटर जो कि संदर्भित है वह नल नहीं है।
व्यवहार में, नल पॉइंटर को डीरेफ़रेंस करने के परिणामस्वरूप मेमोरी से पढ़ने या लिखने का प्रयास किया जा सकता है जो मैप नहीं किया गया है, जिससे सेगमेंटेशन दोष या मेमोरी एक्सेस उल्लंघन प्रारंभ हो सकता है। यह स्वयं प्रोग्राम क्रैश के रूप में प्रकट हो सकता है, या सॉफ़्टवेयर अपवाद हैंडलिंग में परिवर्तित हो सकता है जिसे प्रोग्राम कोड द्वारा पकड़ा जा सकता है। चूँकि, कुछ परिस्थितियाँ ऐसी हैं जहाँ ऐसा नहीं है। उदाहरण के लिए, इंटेल x86 वास्तविक मोड में, एड्रेस 0000:0000 पढ़ने योग्य है और सामान्यतः लिखने योग्य भी है, और उस एड्रेस पर पॉइंटर को डीरेफ़र करना पूर्ण रूप से वैध किंतु सामान्यतः अवांछित कार्रवाई है जो एप्लिकेशन में अपरिभाषित किंतु अक्रैशिंग व्यवहार को उत्पन्न कर सकती है। ऐसा समय होता हैं जब नल को संबोधित करने के लिए पॉइंटर को डीरेफ़रेंस करना और उत्तम रूप से परिभाषित किया जाता है; उदाहरण के लिए,16-बिट रियल-मोड x86 डिवाइस के लिए सी में लिखा गया बायोस कोड, लिखने के लिए नल पॉइंटर को डीरेफ़रेंस करके मशीन के भौतिक एड्रेस 0 पर इंटरप्ट डिस्क्रिप्टर तालिका (IDT) लिख सकता है। कंपाइलर के लिए नल पॉइंटर डेरेफ़रेंस को अनुकूलित करना, विभाजन दोष से बचना, किंतु अन्य अवांछित व्यवहार का कारण बनना भी संभव है।[6]
सी++
सी++ में, जबकि NULL मैक्रो को सी से प्राप्त हुआ था, नल के लिए पूर्णांक शाब्दिक को पारंपरिक रूप से नल पॉइंटर स्थिरांक का प्रतिनिधित्व करने के लिए प्राथमिकता दी गई है।[7] चूँकि, सी++11 ने स्पष्ट नल पॉइंटर स्थिरांक nullptr प्रस्तुत किया और इसके स्थान पर nullptr_t टाइप किया।
अन्य भाषाएँ
कुछ प्रोग्रामिंग भाषा परिवेशों में (उदाहरण के लिए, कम से कम लिस्प कार्यान्वयन) नल पॉइंटर के रूप में उपयोग किया जाने वाला मान (जिसे कहा जाता है) nil लिस्प (प्रोग्रामिंग भाषा) में) वास्तव में कार्यान्वयन के लिए उपयोगी आंतरिक डेटा के ब्लॉक के लिए पॉइंटर हो सकता है (किंतु उपयोगकर्ता प्रोग्रामों से स्पष्ट रूप से पहुंच योग्य नहीं है), इस प्रकार उसी रजिस्टर को उपयोगी स्थिरांक और पहुंच के त्वरित विधि के रूप में उपयोग करने की अनुमति मिलती है इसे nil वेक्टर के रूप में जाना जाता है।
टैग किए गए आर्किटेक्चर वाली भाषाओं में, संभवतः नल पॉइंटर को टैग किए गए संघ से परिवर्तित किया जा सकता है जो असाधारण स्तिथि की स्पष्ट हैंडलिंग को प्रारम्भ करता है; वास्तव में, संभवतः नल पॉइंटर को परिकलित टैग के साथ टैग किए गए पॉइंटर के रूप में देखा जा सकता है।
प्रोग्रामिंग भाषाएं नल पॉइंटर के लिए भिन्न-भिन्न अक्षर का उपयोग करती हैं। उदाहरण के लिए, पायथन में, नल मान को कोई नहीं None कहा जाता है। पास्कल (प्रोग्रामिंग भाषा) और स्विफ्ट (प्रोग्रामिंग भाषा) में, नल पॉइंटर को nil कहा जाता है। एफिल (प्रोग्रामिंग भाषा) में इसे void संदर्भ कहा जाता है ।
अशक्त डीरेफ़रेंसिंग
क्योंकि नल पॉइंटर किसी सार्थक वस्तु को प्रदर्शित नहीं करता है, अशक्त पॉइंटर को डीरेफ़रेंस करने का प्रयास (अर्थात, उस मेमोरी स्थान पर संग्रहीत डेटा तक पहुंच) सामान्यतः (किंतु सदैव नहीं) रन-टाइम त्रुटि या तत्काल प्रोग्राम क्रैश का कारण बनता है। मिटर नल पॉइंटर त्रुटि को सबसे अधिक उपयोग की जाने वाली सॉफ़्टवेयर के रूप में सूचीबद्ध करता है।[8]
सी (प्रोग्रामिंग भाषा) में, नल पॉइंटर को डीरेफ़रेंस करना अपरिभाषित व्यवहार है।[5] कई कार्यान्वयन ऐसे कोड का कारण बनते हैं जिसके परिणामस्वरूप प्रोग्राम को एक्सेस उल्लंघन के साथ अवरोध किया जाता है, क्योंकि नल पॉइंटर प्रतिनिधित्व को ऐसे एड्रेस के रूप में चयन किया जाता है जिसे प्रणाली द्वारा वस्तुओं को संग्रहीत करने के लिए कभी भी आवंटित नहीं किया जाता है। चूँकि, यह व्यवहार सार्वभौमिक नहीं है। इसका भी आश्वासन नहीं है, क्योंकि कंपाइलर्स को इस धारणा के अंतर्गत प्रोग्राम को अनुकूलित करने की अनुमति है कि वे अपरिभाषित व्यवहार से मुक्त हैं।
- डेल्फ़ी (प्रोग्रामिंग भाषा) और कई अन्य पास्कल कार्यान्वयन में, स्थिरांक
nilमेमोरी में पहले एड्रेस पर नल पॉइंटर का प्रतिनिधित्व करता है जिसका उपयोग प्रबंधित चर को प्रारंभ करने के लिए भी किया जाता है। इसे डीरेफ़रेंस करने से बाहरी ओएस अपवाद उत्पन्न होता है जिसे पास्कल पर मैप किया जा रहा हैEAccessViolationअपवाद उदाहरण यदिSystem.SysUtilsइकाई उपयोग खंड में जुड़ी हुई है। - जावा (प्रोग्रामिंग भाषा) में, नल संदर्भ तक पहुंच
NullPointerExceptionको ट्रिगर करती है, जिसे त्रुटि प्रबंधन कोड द्वारा पकड़ा जा सकता है, किंतु लोकप्रिय अभ्यास यह सुनिश्चित करना है कि ऐसे अपवाद कभी न हों। - लिस्प_(प्रोग्रामिंग_भाषा) में,
nilप्रथम श्रेणी की वस्तु है। परंपरा के सन्दर्भ मे,(first nil)nilहै, जैसा कि(rest nil)है। इसलिए डीरेफ़रेंसिंगnilइन संदर्भों में कोई त्रुटि नहीं होगी, किंतु त्रुटिपूर्ण लिखा गया कोड अनंत लूप में जा सकता है। - .NET में, नल संदर्भ तक पहुंच
NullReferenceExceptionको ट्रिगर करती है। चूँकि इन्हें पकड़ना सामान्यतः त्रुटिपूर्ण अभ्यास माना जाता है, इस अपवाद प्रकार को प्रोग्राम द्वारा पकड़ा और नियंत्रित किया जा सकता है। - ऑब्जेक्टिव सी में, प्रोग्राम को बाधित किए बिना संदेशों को
nilऑब्जेक्ट (जो नल पॉइंटर है) पर भेजा जा सकता है; संदेश को सरलता से अप्रत्यक्ष कर दिया जाता है, और प्रकार के आधार पर रिटर्न मान (यदि कोई हो)nilया0, होता है।[9] - सुपरवाइज़र मोड एक्सेस प्रिवेंशन (एसएमएपी) के प्रारंभ से पूर्व, अटैकएर्स में पेजज़ीरो को मैप करके नल पॉइंटर डेरेफ़रेंस बग का लाभ उठाया जा सकता था इस प्रकार नल पॉइंटर उस क्षेत्र को प्रदर्शित कर सकता था। इससे कुछ स्थितियों में कोड निष्पादन हो सकता है।[[10]
शमन
नल पॉइंटर डेरेफ़रेंस को डीबग करने की सुविधा प्रदान करने वाली तकनीकें हैं।[11] बॉन्ड एट अल.[11]अशक्त प्रसार पर निरीक्षण रखने के लिए जावा वर्चुअल मशीन (जेवीएम) को संशोधित करने का विचार दिया जाता है।
कई व्याख्या (कंप्यूटिंग) की गई या वर्चुअल-मशीन भाषाओं में चलने वाली शुद्ध कार्यात्मक भाषाएं और उपयोगकर्ता कोड नल पॉइंटर डीरेफ़रेंसिंग की समस्या से ग्रस्त नहीं होते हैं, क्योंकि पॉइंटर्स तक कोई सरलता से पहुंच प्रदान नहीं की जाती है और, शुद्ध कार्यात्मक भाषाओं की स्तिथि में, सभी कोड और डेटा अपरिवर्तनीय है।
जहां कोई भाषा ऐसे पॉइंटर्स प्रदान या उपयोग करती है जो अन्यथा नल हो सकते हैं, स्थैतिक विश्लेषण या अन्य तकनीकों के माध्यम से संकलन-समय परिक्षण प्रदान करके रनटाइम नल डेरेफ़रेंस को कम करना या उनसे बचना संभव हो सकता है, जैसे कि भाषा सुविधाओं से सिंटेक्टिक सहायता की ओर बढ़ते नियम के साथ जिन्हें एफिल प्रोग्रामिंग भाषा और रस्ट के आधुनिक संस्करणों में देखा गया है।[12] [13] [14]
इतिहास
2009 में, टोनी होरे ने कहा था[15]कि उन्होंने 1965 में एल्गोल डब्ल्यू भाषा के भाग के रूप में नल संदर्भ का आविष्कार किया। 2009 के उस संदर्भ में होरे ने अपने आविष्कार को अरबों डॉलर की त्रुटि के रूप में वर्णित किया है:
मैं इसे अपनी अरबों डॉलर की त्रुटि कहता हूं। यह 1965 में शून्य संदर्भ का आविष्कार था। उस समय, मैं ऑब्जेक्ट ओरिएंटेड लैंग्वेज (ALGOL W) में संदर्भों के लिए पहली व्यापक प्रकार की प्रणाली डिजाइन कर रहा था। मेरा लक्ष्य यह सुनिश्चित करना था कि संदर्भों का सभी उपयोग सुरक्षित होना चाहिए, कंपाइलर द्वारा स्वचालित रूप से परिक्षण किया जाना चाहिए। किन्तु मैं अशक्त संदर्भ डालने के प्रलोभन का विरोध नहीं कर सका, सिर्फ इसलिए क्योंकि इसे प्रारम्भ करना अधिक सरल था। इससे असंख्य त्रुटियाँ और प्रणाली क्रैश हो गए हैं, जिससे संभवतः पूर्व चालीस वर्षों में एक अरब डॉलर की क्षति हुई है।
यह भी देखें
- मेमोरी डिबगर
- नल पृष्ठ
संदर्भ
उद्धरण
- ↑ "CWE-476: NULL Pointer Dereference". MITRE.
- ↑ ISO/IEC 9899, clause 6.3.2.3, paragraph 4.
- ↑ ISO/IEC 9899, clause 7.17, paragraph 3: NULL... which expands to an implementation-defined null pointer constant...
- ↑ ISO/IEC 9899, clause 6.3.2.3, paragraph 3.
- ↑ 5.0 5.1 ISO/IEC 9899, clause 6.5.3.2, paragraph 4, esp. footnote 87.
- ↑ Lattner, Chris (2011-05-13). "What Every C Programmer Should Know About Undefined Behavior #1/3". blog.llvm.org (in English). Archived from the original on 2023-06-14. Retrieved 2023-06-14.
- ↑ Stroustrup, Bjarne (March 2001). "Chapter 5:
Theconstqualifier (§5.4) prevents accidental redefinition ofNULLand ensures thatNULLcan be used where a constant is required.". The C++ Programming Language (14th printing of 3rd ed.). United States and Canada: Addison–Wesley. p. 88. ISBN 0-201-88954-4. - ↑ "CWE-476: NULL Pointer Dereference". MITRE.
- ↑ The Objective-C 2.0 Programming Language, section "Sending Messages to nil".
- ↑ OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl
- ↑ 11.0 11.1 Bond, Michael D.; Nethercote, Nicholas; Kent, Stephen W.; Guyer, Samuel Z.; McKinley, Kathryn S. (2007). "Tracking bad apples". Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07. p. 405. doi:10.1145/1297027.1297057. ISBN 9781595937865. S2CID 2832749.
- ↑ "Void-safety: Background, definition, and tools". Retrieved 2021-11-24.
- ↑ Bartosz Milewski. "SafeD – D Programming Language". Retrieved 17 July 2014.
- ↑ "Fearless Security: Memory Safety". Archived from the original on 8 November 2020. Retrieved 4 November 2020.
- ↑ Tony Hoare (2009-08-25). "Null References: The Billion Dollar Mistake". InfoQ.com.
स्रोत
- Joint Technical Committee ISO/IEC JTC 1, Subcommittee SC 22, Working Group WG 14 (2007-09-08). अंतर्राष्ट्रीय मानक आईएसओ/आईईसी 9899 (PDF) (Committee Draft).
{{cite book}}: CS1 maint: multiple names: authors list (link)
श्रेणी:डेटा प्रकार
