नल पॉइंटर: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 1: Line 1:
{{Short description|Value indicating that a referenced dataset is invalid or doesn't exist}}
{{Short description|Value indicating that a referenced dataset is invalid or doesn't exist}}


[[ कम्प्यूटिंग ]] में, शून्य सूचक या शून्य संदर्भ यह इंगित करने के लिए सहेजा गया मान है कि सूचक (कंप्यूटर प्रोग्रामिंग) या [[संदर्भ (कंप्यूटर विज्ञान)]] वैध ऑब्जेक्ट (कंप्यूटर विज्ञान) को संदर्भित नहीं करता है। प्रोग्राम नियमित रूप से अज्ञात लंबाई की [[सूची (कंप्यूटिंग)]] के अंत या कुछ कार्रवाई करने में विफलता जैसी स्थितियों का प्रतिनिधित्व करने के लिए शून्य पॉइंटर्स का उपयोग करते हैं; अशक्त सूचकों के इस उपयोग की तुलना अशक्त प्रकारों और [[विकल्प प्रकार]] में ''कुछ नहीं'' मान से की जा सकती है।
[[ कम्प्यूटिंग |कम्प्यूटिंग]] में, नल पॉइंटर या नल संदर्भ यह प्रदर्शित करने के लिए सहेजा गया मान है कि पॉइंटर (कंप्यूटर प्रोग्रामिंग) या [[संदर्भ (कंप्यूटर विज्ञान)]] वैध ऑब्जेक्ट (कंप्यूटर विज्ञान) को संदर्भित नहीं करता है। प्रोग्राम नियमित रूप से अज्ञात लंबाई की [[सूची (कंप्यूटिंग)]] के अंत या कुछ कार्रवाई करने में विफलता जैसी स्थितियों का प्रतिनिधित्व करने के लिए नल पॉइंटर्स का उपयोग करते हैं; अशक्त पॉइंटरों के इस उपयोग की तुलना अशक्त प्रकारों और [[विकल्प प्रकार]] में कुछ भी नहीं मान से की जा सकती है।


अशक्त सूचक को [[अप्रारंभीकृत चर]] के साथ भ्रमित नहीं किया जाना चाहिए: अशक्त सूचक को किसी वैध वस्तु को इंगित करने वाले किसी भी सूचक के साथ असमान तुलना करने की गारंटी दी जाती है। हालाँकि, भाषा और कार्यान्वयन के आधार पर, अप्रारंभीकृत सूचक के पास ऐसी कोई गारंटी नहीं हो सकती है। इसकी तुलना अन्य, मान्य संकेतकों के बराबर हो सकती है; या इसकी तुलना शून्य सूचकों के बराबर हो सकती है। यह अलग-अलग समय पर दोनों कार्य कर सकता है; या तुलना [[अपरिभाषित व्यवहार]] हो सकती है।
अशक्त पॉइंटर को [[अप्रारंभीकृत चर]] के साथ भ्रमित नहीं किया जाना चाहिए: अशक्त पॉइंटर को किसी वैध वस्तु को प्रदर्शित करने वाले किसी भी पॉइंटर के साथ असमान तुलना करने की आश्वासन दिया जाता है। चूँकि, भाषा और कार्यान्वयन के आधार पर, अप्रारंभीकृत पॉइंटर के पास ऐसा कोई आश्वासन नहीं हो सकता है। इसकी तुलना अन्य, मान्य संकेतकों के समान हो सकती है; या इसकी तुलना नल पॉइंटरों के समान हो सकती है। यह भिन्न-भिन्न समय पर दोनों कार्य कर सकता है; या तुलना [[अपरिभाषित व्यवहार]] हो सकती है।


क्योंकि शून्य सूचक किसी सार्थक वस्तु को इंगित नहीं करता है, उस (अमान्य) मेमोरी स्थान पर संग्रहीत डेटा तक पहुंचने का प्रयास रन-टाइम त्रुटि या तत्काल प्रोग्राम क्रैश का कारण बन सकता है। यह शून्य सूचक त्रुटि है. यह सबसे सामान्य प्रकार की सॉफ़्टवेयर कमज़ोरियों में से है,<ref>{{cite web |url=https://cwe.mitre.org/data/definitions/476.html |title=CWE-476: NULL Pointer Dereference |website=MITRE}}</ref> और इस अवधारणा को पेश करने वाले [[टोनी होरे]] ने इसे अरब डॉलर की गलती के रूप में संदर्भित किया है।
क्योंकि नल पॉइंटर किसी सार्थक वस्तु को प्रदर्शित नहीं करता है, उस (अमान्य) मेमोरी स्थान पर संग्रहीत डेटा तक पहुंचने का प्रयास रन-टाइम त्रुटि या तत्काल प्रोग्राम क्रैश का कारण बन सकता है। यह नल पॉइंटर त्रुटि है, यह सबसे सामान्य प्रकार की सॉफ़्टवेयर अशक्त में से है,<ref>{{cite web |url=https://cwe.mitre.org/data/definitions/476.html |title=CWE-476: NULL Pointer Dereference |website=MITRE}}</ref> और इस अवधारणा को प्रस्तुत करने वाले [[टोनी होरे]] ने इसे अरब डॉलर की त्रुटि के रूप में संदर्भित किया है।


== सी ==
== सी ==


[[सी (प्रोग्रामिंग भाषा)]] में, किसी भी प्रकार के दो शून्य पॉइंटर्स की तुलना बराबर होने की गारंटी दी जाती है।<ref>[[#c-std|ISO/IEC 9899]], clause 6.3.2.3, paragraph 4.</ref> प्रीप्रोसेसर मैक्रो <code>NULL</code> में कार्यान्वयन-परिभाषित शून्य सूचक स्थिरांक के रूप में परिभाषित किया गया है <code><[[stdlib.h]]></code>,<ref>[[#c-std|ISO/IEC 9899]], clause 7.17, paragraph 3: ''NULL... which expands to an implementation-defined null pointer constant...''</ref> जिसे [[C99]] में पोर्टेबल रूप से व्यक्त किया जा सकता है <code>((void *)0)</code> जिसका अर्थ है कि पूर्णांक मान <code>0</code> प्रकार में परिवर्तित किया गया <code>void*</code> ([[शून्य प्रकार]] का सूचक)।<ref>[[#c-std|ISO/IEC 9899]], clause 6.3.2.3, paragraph 3.</ref> सी मानक यह नहीं कहता है कि नल पॉइंटर [[ स्मृति पता ]] 0 के पॉइंटर के समान है, हालांकि व्यवहार में ऐसा हो सकता है। शून्य सूचक को असंदर्भित करना C में अपरिभाषित व्यवहार है,<ref name="ub"/>और अनुरूप कार्यान्वयन को यह मानने की अनुमति है कि कोई भी सूचक जो कि संदर्भित है वह शून्य नहीं है।
[[सी (प्रोग्रामिंग भाषा)]] में, किसी भी प्रकार के दो नल पॉइंटर्स की तुलना समान होने का आश्वासन दिया जाता है।<ref>[[#c-std|ISO/IEC 9899]], clause 6.3.2.3, paragraph 4.</ref> प्रीप्रोसेसर मैक्रो <code>NULL</code> को <code><[[stdlib.h]]></code> में कार्यान्वयन-परिभाषित नल पॉइंटर स्थिरांक के रूप में परिभाषित किया गया है,<ref>[[#c-std|ISO/IEC 9899]], clause 7.17, paragraph 3: ''NULL... which expands to an implementation-defined null pointer constant...''</ref> जिसे [[C99|सी99]] में पोर्टेबल रूप से <code>((void *)0)</code> व्यक्त किया जा सकता है जिसका अर्थ है कि पूर्णांक मान <code>0</code> प्रकार में परिवर्तित हो जाता है <code>void*</code> ([[शून्य प्रकार|नल प्रकार]] का पॉइंटर)।<ref>[[#c-std|ISO/IEC 9899]], clause 6.3.2.3, paragraph 3.</ref> सी मानक यह नहीं कहता है कि नल पॉइंटर [[ स्मृति पता |मेमोरी एड्रेस]] 0 के पॉइंटर के समान है, चूँकि व्यवहार में ऐसा हो सकता है। नल पॉइंटर को असंदर्भित करना सी में अपरिभाषित व्यवहार है,<ref name="ub"/>और अनुरूप कार्यान्वयन को यह मानने की अनुमति है कि कोई भी पॉइंटर जो कि संदर्भित है वह नल नहीं है।


व्यवहार में, शून्य पॉइंटर को डीरेफ़रेंस करने के परिणामस्वरूप [[ स्मृति ]] से पढ़ने या लिखने का प्रयास किया जा सकता है जो मैप नहीं किया गया है, जिससे [[विखंडन दोष]] या मेमोरी ्सेस उल्लंघन शुरू हो सकता है। यह स्वयं प्रोग्राम क्रैश के रूप में प्रकट हो सकता है, या सॉफ़्टवेयर अपवाद हैंडलिंग में परिवर्तित हो सकता है जिसे प्रोग्राम कोड द्वारा पकड़ा जा सकता है। हालाँकि, कुछ परिस्थितियाँ ऐसी हैं जहाँ ऐसा नहीं है। उदाहरण के लिए, [[Intel x86]] वास्तविक मोड में, पता <code>0000:0000</code> पढ़ने योग्य है और आमतौर पर लिखने योग्य भी है, और उस पते पर पॉइंटर को डीरेफ़र करना पूरी तरह से वैध लेकिन आम तौर पर अवांछित कार्रवाई है जो एप्लिकेशन में अपरिभाषित लेकिन गैर-क्रैशिंग व्यवहार को जन्म दे सकती है। ऐसे अवसर होते हैं जब शून्य को संबोधित करने के लिए सूचक को डीरेफ़रेंस करना जानबूझकर और अच्छी तरह से परिभाषित किया जाता है; उदाहरण के लिए, 16-बिट रियल-मोड x86 डिवाइस के लिए C में लिखा गया [[BIOS]] कोड, लिखने के लिए नल पॉइंटर को डीरेफ़रेंस करके मशीन के भौतिक पते 0 पर [[ इंटरप्ट डिस्क्रिप्टर तालिका ]] (IDT) लिख सकता है। कंपाइलर के लिए शून्य पॉइंटर डेरेफ़रेंस को अनुकूलित करना, विभाजन दोष से बचना, लेकिन अन्य अवांछित व्यवहार का कारण बनना भी संभव है।<ref>{{Cite web |last=Lattner |first=Chris |date=2011-05-13 |title=What Every C Programmer Should Know About Undefined Behavior #1/3 |url=https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html |url-status=live |archive-url=https://web.archive.org/web/20230614124121/https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html |archive-date=2023-06-14 |access-date=2023-06-14 |website=blog.llvm.org |language=en}}</ref>
व्यवहार में, नल पॉइंटर को डीरेफ़रेंस करने के परिणामस्वरूप [[ स्मृति |मेमोरी]] से पढ़ने या लिखने का प्रयास किया जा सकता है जो मैप नहीं किया गया है, जिससे [[विखंडन दोष|सेगमेंटेशन दोष]] या मेमोरी एक्सेस  उल्लंघन प्रारंभ हो सकता है। यह स्वयं प्रोग्राम क्रैश के रूप में प्रकट हो सकता है, या सॉफ़्टवेयर अपवाद हैंडलिंग में परिवर्तित हो सकता है जिसे प्रोग्राम कोड द्वारा पकड़ा जा सकता है। चूँकि, कुछ परिस्थितियाँ ऐसी हैं जहाँ ऐसा नहीं है। उदाहरण के लिए, [[Intel x86|इंटेलl x86]] वास्तविक मोड में, एड्रेस <code>0000:0000</code> पढ़ने योग्य है और सामान्यतः लिखने योग्य भी है, और उस एड्रेस पर पॉइंटर को डीरेफ़र करना पूर्ण रूप से वैध किंतु सामान्यतः अवांछित कार्रवाई है जो एप्लिकेशन में अपरिभाषित किंतु अक्रैशिंग व्यवहार को उत्पन्न कर सकती है। ऐसा समय होता हैं जब नल को संबोधित करने के लिए पॉइंटर को डीरेफ़रेंस करना और उत्तम रूप से परिभाषित किया जाता है; उदाहरण के लिए, 16-बिट रियल-मोड x86 डिवाइस के लिए सी में लिखा गया [[BIOS|बायोस]] कोड, लिखने के लिए नल पॉइंटर को डीरेफ़रेंस करके मशीन के भौतिक एड्रेस 0 पर [[ इंटरप्ट डिस्क्रिप्टर तालिका |इंटरप्ट डिस्क्रिप्टर तालिका]] (IDT) लिख सकता है। कंपाइलर के लिए नल पॉइंटर डेरेफ़रेंस को अनुकूलित करना, विभाजन दोष से बचना, किंतु अन्य अवांछित व्यवहार का कारण बनना भी संभव है।<ref>{{Cite web |last=Lattner |first=Chris |date=2011-05-13 |title=What Every C Programmer Should Know About Undefined Behavior #1/3 |url=https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html |url-status=live |archive-url=https://web.archive.org/web/20230614124121/https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html |archive-date=2023-06-14 |access-date=2023-06-14 |website=blog.llvm.org |language=en}}</ref>


== सी++ ==
== सी++ ==
C++ में, जबकि <code>NULL</code> मैक्रो को C से विरासत में मिला था, शून्य के लिए पूर्णांक शाब्दिक को पारंपरिक रूप से शून्य सूचक स्थिरांक का प्रतिनिधित्व करने के लिए प्राथमिकता दी गई है।<ref>{{cite book |last1=Stroustrup |first=Bjarne |authorlink1=Bjarne_Stroustrup |title=[[The C++ Programming Language]] |edition=14th printing of 3rd |date=March 2001 |publisher=Addison–Wesley |location=United States and Canada |isbn=0-201-88954-4 |page=[https://archive.org/details/cprogramminglang00stro_0/page/88 88] |chapter=Chapter 5: <br />The <code>const</code> qualifier (§5.4) prevents accidental redefinition of <code>NULL</code> and ensures that <code>NULL</code> can be used where a constant is required. }}</ref> हालाँकि, [[C++11]] ने स्पष्ट शून्य सूचक स्थिरांक प्रस्तुत किया <code>[[nullptr]]</code> और टाइप करें <code>[[nullptr_t]]</code> इसके स्थान पर उपयोग किया जाना है।
सी++ में, जबकि <code>NULL</code> मैक्रो को सी से प्राप्त हुआ था, नल के लिए पूर्णांक शाब्दिक को पारंपरिक रूप से नल पॉइंटर स्थिरांक का प्रतिनिधित्व करने के लिए प्राथमिकता दी गई है।<ref>{{cite book |last1=Stroustrup |first=Bjarne |authorlink1=Bjarne_Stroustrup |title=[[The C++ Programming Language]] |edition=14th printing of 3rd |date=March 2001 |publisher=Addison–Wesley |location=United States and Canada |isbn=0-201-88954-4 |page=[https://archive.org/details/cprogramminglang00stro_0/page/88 88] |chapter=Chapter 5: <br />The <code>const</code> qualifier (§5.4) prevents accidental redefinition of <code>NULL</code> and ensures that <code>NULL</code> can be used where a constant is required. }}</ref> चूँकि, [[C++11|सी++11]] ने स्पष्ट नल पॉइंटर स्थिरांक <code>[[nullptr]]</code> प्रस्तुत किया और इसके स्थान पर <code>[[nullptr_t]]</code> टाइप किया।


== अन्य भाषाएँ ==
== अन्य भाषाएँ ==


कुछ प्रोग्रामिंग भाषा परिवेशों में (उदाहरण के लिए, कम से कम मालिकाना लिस्प कार्यान्वयन),{{citation needed|date=September 2011}} शून्य सूचक के रूप में उपयोग किया जाने वाला मान (जिसे कहा जाता है)<code>nil</code> [[लिस्प (प्रोग्रामिंग भाषा)]] में) वास्तव में कार्यान्वयन के लिए उपयोगी आंतरिक डेटा के ब्लॉक के लिए सूचक हो सकता है (लेकिन उपयोगकर्ता कार्यक्रमों से स्पष्ट रूप से पहुंच योग्य नहीं है), इस प्रकार उसी रजिस्टर को उपयोगी स्थिरांक और पहुंच के त्वरित तरीके के रूप में उपयोग करने की अनुमति मिलती है कार्यान्वयन आंतरिक. इसे के नाम से जाना जाता है <code>nil</code> वेक्टर।
कुछ प्रोग्रामिंग भाषा परिवेशों में (उदाहरण के लिए, कम से कम लिस्प कार्यान्वयन) नल पॉइंटर के रूप में उपयोग किया जाने वाला मान (जिसे कहा जाता है) <code>nil</code> [[लिस्प (प्रोग्रामिंग भाषा)]] में) वास्तव में कार्यान्वयन के लिए उपयोगी आंतरिक डेटा के ब्लॉक के लिए पॉइंटर हो सकता है (किंतु उपयोगकर्ता प्रोग्रामों से स्पष्ट रूप से पहुंच योग्य नहीं है), इस प्रकार उसी रजिस्टर को उपयोगी स्थिरांक और पहुंच के त्वरित विधि के रूप में उपयोग करने की अनुमति मिलती है इसे <code>nil</code> वेक्टर के रूप में जाना जाता है।


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


प्रोग्रामिंग भाषाएं नल पॉइंटर के लिए अलग-अलग अक्षर का उपयोग करती हैं। उदाहरण के लिए, पायथन में, शून्य मान कहा जाता है <code>None</code>. [[पास्कल (प्रोग्रामिंग भाषा)]] और [[स्विफ्ट (प्रोग्रामिंग भाषा)]] में, नल पॉइंटर कहा जाता है <code>nil</code>. [[एफिल (प्रोग्रामिंग भाषा)]] में इसे a कहा जाता है <code>void</code> संदर्भ।
प्रोग्रामिंग भाषाएं नल पॉइंटर के लिए भिन्न-भिन्न अक्षर का उपयोग करती हैं। उदाहरण के लिए, पायथन में, नल मान को कोई नहीं <code>None</code> कहा जाता है। [[पास्कल (प्रोग्रामिंग भाषा)]] और [[स्विफ्ट (प्रोग्रामिंग भाषा)]] में, नल पॉइंटर को <code>nil</code> कहा जाता है। [[एफिल (प्रोग्रामिंग भाषा)]] में इसे <code>void</code> संदर्भ कहा जाता है ।


== अशक्त [[भिन्नता]]िंग ==
== अशक्त [[भिन्नता|डीरेफ़रेंसिंग]] ==


क्योंकि शून्य सूचक किसी सार्थक वस्तु को इंगित नहीं करता है, अशक्त सूचक को डीरेफ़रेंस करने का प्रयास (यानी, उस मेमोरी स्थान पर संग्रहीत डेटा तक पहुंच) आमतौर पर (लेकिन हमेशा नहीं) रन-टाइम त्रुटि या तत्काल प्रोग्राम क्रैश का कारण बनता है। MITER नल पॉइंटर त्रुटि को सबसे अधिक उपयोग की जाने वाली सॉफ़्टवेयर कमज़ोरियों में से  के रूप में सूचीबद्ध करता है।<ref>{{cite web |url=https://cwe.mitre.org/data/definitions/476.html |title=CWE-476: NULL Pointer Dereference |website=MITRE}}</ref> * सी (प्रोग्रामिंग भाषा) में,  नल पॉइंटर को डीरेफ़रेंस करना अपरिभाषित व्यवहार है।<ref name="ub">[[#c-std|ISO/IEC 9899]], clause 6.5.3.2, paragraph 4, esp. footnote 87.</ref> कई कार्यान्वयन ऐसे कोड का कारण बनते हैं जिसके परिणामस्वरूप प्रोग्राम को ्सेस उल्लंघन के साथ रोक दिया जाता है, क्योंकि नल पॉइंटर प्रतिनिधित्व को  ऐसे पते के रूप में चुना जाता है जिसे सिस्टम द्वारा वस्तुओं को संग्रहीत करने के लिए कभी भी आवंटित नहीं किया जाता है। हालाँकि, यह व्यवहार सार्वभौमिक नहीं है। इसकी भी गारंटी नहीं है, क्योंकि कंपाइलर्स को इस धारणा के तहत प्रोग्राम को अनुकूलित करने की अनुमति है कि वे अपरिभाषित व्यवहार से मुक्त हैं।
क्योंकि नल पॉइंटर किसी सार्थक वस्तु को प्रदर्शित नहीं करता है, अशक्त पॉइंटर को डीरेफ़रेंस करने का प्रयास (अर्थात, उस मेमोरी स्थान पर संग्रहीत डेटा तक पहुंच) सामान्यतः (किंतु सदैव नहीं) रन-टाइम त्रुटि या तत्काल प्रोग्राम क्रैश का कारण बनता है। मिटर नल पॉइंटर त्रुटि को सबसे अधिक उपयोग की जाने वाली सॉफ़्टवेयर के रूप में सूचीबद्ध करता है।<ref>{{cite web |url=https://cwe.mitre.org/data/definitions/476.html |title=CWE-476: NULL Pointer Dereference |website=MITRE}}</ref>


* [[डेल्फ़ी (प्रोग्रामिंग भाषा)]] और कई अन्य पास्कल कार्यान्वयन में, स्थिरांक <code>nil</code> मेमोरी में पहले पते पर शून्य सूचक का प्रतिनिधित्व करता है जिसका उपयोग प्रबंधित चर को प्रारंभ करने के लिए भी किया जाता है। इसे डीरेफ़रेंस करने से बाहरी OS अपवाद उत्पन्न होता है जिसे पास्कल पर मैप किया जा रहा है {{code|EAccessViolation}} अपवाद उदाहरण यदि {{code|System.SysUtils}} इकाई उपयोग खंड में जुड़ी हुई है।
सी (प्रोग्रामिंग भाषा) में, नल पॉइंटर को डीरेफ़रेंस करना अपरिभाषित व्यवहार है।<ref name="ub">[[#c-std|ISO/IEC 9899]], clause 6.5.3.2, paragraph 4, esp. footnote 87.</ref> कई कार्यान्वयन ऐसे कोड का कारण बनते हैं जिसके परिणामस्वरूप प्रोग्राम को एक्सेस उल्लंघन के साथ अवरोध किया जाता है, क्योंकि नल पॉइंटर प्रतिनिधित्व को ऐसे एड्रेस के रूप में चयन किया जाता है जिसे प्रणाली द्वारा वस्तुओं को संग्रहीत करने के लिए कभी भी आवंटित नहीं किया जाता है। चूँकि, यह व्यवहार सार्वभौमिक नहीं है। इसका भी आश्वासन नहीं है, क्योंकि कंपाइलर्स को इस धारणा के अंतर्गत प्रोग्राम को अनुकूलित करने की अनुमति है कि वे अपरिभाषित व्यवहार से मुक्त हैं।
* [[जावा (प्रोग्रामिंग भाषा)]] में, शून्य संदर्भ तक पहुंच ट्रिगर होती है {{Javadoc:SE|java/lang|NullPointerException}} (एनपीई), जिसे त्रुटि प्रबंधन कोड द्वारा पकड़ा जा सकता है, लेकिन पसंदीदा अभ्यास यह सुनिश्चित करना है कि ऐसे अपवाद कभी न हों।
 
* लिस्प_(प्रोग्रामिंग_भाषा) में, {{code|nil}} प्रथम श्रेणी की वस्तु है। रिवाज के सन्दर्भ मे, <code>(first nil)</code> है {{code|nil}}, जैसा है <code>(rest nil)</code>. इसलिए डीरेफ़रेंसिंग {{code|nil}} इन संदर्भों में कोई त्रुटि नहीं होगी, लेकिन खराब लिखा गया कोड अनंत लूप में जा सकता है।
* [[डेल्फ़ी (प्रोग्रामिंग भाषा)]] और कई अन्य पास्कल कार्यान्वयन में, स्थिरांक <code>nil</code> मेमोरी में पहले एड्रेस पर नल पॉइंटर का प्रतिनिधित्व करता है जिसका उपयोग प्रबंधित चर को प्रारंभ करने के लिए भी किया जाता है। इसे डीरेफ़रेंस करने से बाहरी ओएस अपवाद उत्पन्न होता है जिसे पास्कल पर मैप किया जा रहा है {{code|EAccessViolation}} अपवाद उदाहरण यदि {{code|System.SysUtils}} इकाई उपयोग खंड में जुड़ी हुई है।
* .Net (प्रोग्रामिंग भाषा)|.NET में, शून्य संदर्भ तक पहुंच ट्रिगर होती है {{code|NullReferenceException}}फेंका जाना। हालाँकि इन्हें पकड़ना आम तौर पर खराब अभ्यास माना जाता है, इस अपवाद प्रकार को प्रोग्राम द्वारा पकड़ा और नियंत्रित किया जा सकता है।
* [[जावा (प्रोग्रामिंग भाषा)]] में, नल संदर्भ तक पहुंच {{Javadoc:SE|java/lang|NullPointerException}} को ट्रिगर  करती है, जिसे त्रुटि प्रबंधन कोड द्वारा पकड़ा जा सकता है, किंतु लोकप्रिय अभ्यास यह सुनिश्चित करना है कि ऐसे अपवाद कभी न हों।
* [[ उद्देश्य सी ]] में, संदेश भेजे जा सकते हैं <code>nil</code> प्रोग्राम को बाधित किए बिना ऑब्जेक्ट (जो शून्य सूचक है); संदेश को आसानी से अनदेखा कर दिया जाता है, और वापसी मान (यदि कोई हो) है <code>nil</code> या <code>0</code>, प्रकार पर निर्भर करता है।<ref>''The Objective-C 2.0 Programming Language'', [https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-SW7 section "Sending Messages to nil"].</ref>
* लिस्प_(प्रोग्रामिंग_भाषा) में, {{code|nil}} प्रथम श्रेणी की वस्तु है। परंपरा के सन्दर्भ मे, <code>(first nil)</code> {{code|nil}} है, जैसा कि <code>(rest nil)</code> है। इसलिए डीरेफ़रेंसिंग {{code|nil}} इन संदर्भों में कोई त्रुटि नहीं होगी, किंतु त्रुटिपूर्ण लिखा गया कोड अनंत लूप में जा सकता है।
* [[पर्यवेक्षक मोड पहुंच रोकथाम]] (एसएमएपी) की शुरुआत से पहले, [[शून्य पृष्ठ]] को हमलावर के [[पता स्थान]] में मैप करके  नल पॉइंटर डेरेफ़रेंस बग का फायदा उठाया जा सकता था और इस प्रकार नल पॉइंटर उस क्षेत्र को इंगित कर सकता था। इससे कुछ मामलों में [[मनमाना कोड निष्पादन]] हो सकता है।<ref>[https://bugs.chromium.org/p/project-zero/issues/detail?id=782&can=1&q=null%20pointer&sort=-reported&colspec=ID%20Status%20Restrict%20Reported%20Vendor%20Product%20Finder%20Summary OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl]</ref>
* .NET में, नल संदर्भ तक पहुंच {{code|NullReferenceException}} को ट्रिगर करती है। चूँकि इन्हें पकड़ना सामान्यतः त्रुटिपूर्ण अभ्यास माना जाता है, इस अपवाद प्रकार को प्रोग्राम द्वारा पकड़ा और नियंत्रित किया जा सकता है।
* [[ उद्देश्य सी |ऑब्जेक्टिव सी]] में, प्रोग्राम को बाधित किए बिना संदेशों को <code>nil</code> ऑब्जेक्ट (जो नल पॉइंटर है) पर भेजा जा सकता है; संदेश को सरलता से अप्रत्यक्ष कर दिया जाता है, और प्रकार के आधार पर रिटर्न मान (यदि कोई हो) <code>nil</code> या <code>0</code>, होता है।<ref>''The Objective-C 2.0 Programming Language'', [https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html#//apple_ref/doc/uid/TP30001163-CH11-SW7 section "Sending Messages to nil"].</ref>
* [[पर्यवेक्षक मोड पहुंच रोकथाम|सुपरवाइज़र मोड एक्सेस प्रिवेंशन]] (एसएमएपी) के प्रारंभ से पूर्व, अटैकएर्स में पेजज़ीरो को मैप करके [[शून्य पृष्ठ|नल पॉइंटर]] डेरेफ़रेंस बग का लाभ उठाया जा सकता था इस प्रकार नल पॉइंटर उस क्षेत्र को प्रदर्शित कर सकता था। इससे कुछ स्थितियों में [[मनमाना कोड निष्पादन|कोड निष्पादन]] हो सकता है।[<ref>[https://bugs.chromium.org/p/project-zero/issues/detail?id=782&can=1&q=null%20pointer&sort=-reported&colspec=ID%20Status%20Restrict%20Reported%20Vendor%20Product%20Finder%20Summary OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl]</ref>


== शमन ==
== शमन ==
Line 40: Line 42:
कई [[दुभाषिया (कंप्यूटिंग)]] या वर्चुअल-मशीन भाषाओं में चलने वाली शुद्ध कार्यात्मक भाषाएं और उपयोगकर्ता कोड नल पॉइंटर डीरेफ़रेंसिंग की समस्या से ग्रस्त नहीं होते हैं, क्योंकि पॉइंटर्स तक कोई सीधी पहुंच प्रदान नहीं की जाती है और, शुद्ध कार्यात्मक भाषाओं के मामले में, सभी कोड और डेटा अपरिवर्तनीय है.
कई [[दुभाषिया (कंप्यूटिंग)]] या वर्चुअल-मशीन भाषाओं में चलने वाली शुद्ध कार्यात्मक भाषाएं और उपयोगकर्ता कोड नल पॉइंटर डीरेफ़रेंसिंग की समस्या से ग्रस्त नहीं होते हैं, क्योंकि पॉइंटर्स तक कोई सीधी पहुंच प्रदान नहीं की जाती है और, शुद्ध कार्यात्मक भाषाओं के मामले में, सभी कोड और डेटा अपरिवर्तनीय है.


जहां कोई भाषा ऐसे पॉइंटर्स प्रदान या उपयोग करती है जो अन्यथा शून्य हो सकते हैं, [[स्थैतिक विश्लेषण]] या अन्य तकनीकों के माध्यम से संकलन-समय जांच प्रदान करके रनटाइम नल डेरेफ़रेंस को कम करना या उनसे बचना संभव हो सकता है, जैसे कि भाषा सुविधाओं से सिंटेक्टिक सहायता की ओर बढ़ते आंदोलन के साथ। जिन्हें [[एफिल प्रोग्रामिंग भाषा]] के आधुनिक संस्करणों में देखा गया है,<ref>{{cite web | url=https://www.eiffel.org/doc/eiffel/Void-safety-_Background%2C_definition%2C_and_tools |title=Void-safety: Background, definition, and tools|access-date=2021-11-24 }}</ref> [[डी प्रोग्रामिंग भाषा]],<ref name="SafeD">{{cite web |title=SafeD – D Programming Language |url=http://dlang.org/safed.html |author=Bartosz Milewski |access-date=17 July 2014}}</ref> और रस्ट प्रोग्रामिंग भाषा।<ref>{{cite web|title=Fearless Security: Memory Safety|url=https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/|access-date=4 November 2020|archive-date=8 November 2020|archive-url=https://web.archive.org/web/20201108003116/https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/|url-status=live}}</ref>
जहां कोई भाषा ऐसे पॉइंटर्स प्रदान या उपयोग करती है जो अन्यथा नल हो सकते हैं, [[स्थैतिक विश्लेषण]] या अन्य तकनीकों के माध्यम से संकलन-समय जांच प्रदान करके रनटाइम नल डेरेफ़रेंस को कम करना या उनसे बचना संभव हो सकता है, जैसे कि भाषा सुविधाओं से सिंटेक्टिक सहायता की ओर बढ़ते आंदोलन के साथ। जिन्हें [[एफिल प्रोग्रामिंग भाषा]] के आधुनिक संस्करणों में देखा गया है,<ref>{{cite web | url=https://www.eiffel.org/doc/eiffel/Void-safety-_Background%2C_definition%2C_and_tools |title=Void-safety: Background, definition, and tools|access-date=2021-11-24 }}</ref> [[डी प्रोग्रामिंग भाषा]],<ref name="SafeD">{{cite web |title=SafeD – D Programming Language |url=http://dlang.org/safed.html |author=Bartosz Milewski |access-date=17 July 2014}}</ref> और रस्ट प्रोग्रामिंग भाषा।<ref>{{cite web|title=Fearless Security: Memory Safety|url=https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/|access-date=4 November 2020|archive-date=8 November 2020|archive-url=https://web.archive.org/web/20201108003116/https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/|url-status=live}}</ref>
कुछ भाषाओं में बाहरी उपकरणों का उपयोग करके समान विश्लेषण किया जा सकता है।
कुछ भाषाओं में बाहरी उपकरणों का उपयोग करके समान विश्लेषण किया जा सकता है।


Line 53: Line 55:
|author-link=Tony Hoare
|author-link=Tony Hoare
}}</ref>
}}</ref>
उन्होंने 1965 में [[ALGOL W]] भाषा के भाग के रूप में शून्य संदर्भ का आविष्कार किया। 2009 के उस संदर्भ में होरे ने अपने आविष्कार को अरबों डॉलर की गलती के रूप में वर्णित किया है:
उन्होंने 1965 में [[ALGOL W]] भाषा के भाग के रूप में नल संदर्भ का आविष्कार किया। 2009 के उस संदर्भ में होरे ने अपने आविष्कार को अरबों डॉलर की त्रुटि के रूप में वर्णित किया है:
{{quote|I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.}}
{{quote|I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.}}


==यह भी देखें==
==यह भी देखें==
* [[मेमोरी डिबगर]]
* [[मेमोरी डिबगर]]
* शून्य पृष्ठ
* नल पृष्ठ


== संदर्भ ==
== संदर्भ ==

Revision as of 12:18, 16 July 2023

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

अशक्त पॉइंटर को अप्रारंभीकृत चर के साथ भ्रमित नहीं किया जाना चाहिए: अशक्त पॉइंटर को किसी वैध वस्तु को प्रदर्शित करने वाले किसी भी पॉइंटर के साथ असमान तुलना करने की आश्वासन दिया जाता है। चूँकि, भाषा और कार्यान्वयन के आधार पर, अप्रारंभीकृत पॉइंटर के पास ऐसा कोई आश्वासन नहीं हो सकता है। इसकी तुलना अन्य, मान्य संकेतकों के समान हो सकती है; या इसकी तुलना नल पॉइंटरों के समान हो सकती है। यह भिन्न-भिन्न समय पर दोनों कार्य कर सकता है; या तुलना अपरिभाषित व्यवहार हो सकती है।

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

सी

सी (प्रोग्रामिंग भाषा) में, किसी भी प्रकार के दो नल पॉइंटर्स की तुलना समान होने का आश्वासन दिया जाता है।[2] प्रीप्रोसेसर मैक्रो NULL को <stdlib.h> में कार्यान्वयन-परिभाषित नल पॉइंटर स्थिरांक के रूप में परिभाषित किया गया है,[3] जिसे सी99 में पोर्टेबल रूप से ((void *)0) व्यक्त किया जा सकता है जिसका अर्थ है कि पूर्णांक मान 0 प्रकार में परिवर्तित हो जाता है void* (नल प्रकार का पॉइंटर)।[4] सी मानक यह नहीं कहता है कि नल पॉइंटर मेमोरी एड्रेस 0 के पॉइंटर के समान है, चूँकि व्यवहार में ऐसा हो सकता है। नल पॉइंटर को असंदर्भित करना सी में अपरिभाषित व्यवहार है,[5]और अनुरूप कार्यान्वयन को यह मानने की अनुमति है कि कोई भी पॉइंटर जो कि संदर्भित है वह नल नहीं है।

व्यवहार में, नल पॉइंटर को डीरेफ़रेंस करने के परिणामस्वरूप मेमोरी से पढ़ने या लिखने का प्रयास किया जा सकता है जो मैप नहीं किया गया है, जिससे सेगमेंटेशन दोष या मेमोरी एक्सेस उल्लंघन प्रारंभ हो सकता है। यह स्वयं प्रोग्राम क्रैश के रूप में प्रकट हो सकता है, या सॉफ़्टवेयर अपवाद हैंडलिंग में परिवर्तित हो सकता है जिसे प्रोग्राम कोड द्वारा पकड़ा जा सकता है। चूँकि, कुछ परिस्थितियाँ ऐसी हैं जहाँ ऐसा नहीं है। उदाहरण के लिए, इंटेलl 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 में ALGOL W भाषा के भाग के रूप में नल संदर्भ का आविष्कार किया। 2009 के उस संदर्भ में होरे ने अपने आविष्कार को अरबों डॉलर की त्रुटि के रूप में वर्णित किया है:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

यह भी देखें

संदर्भ

उद्धरण

  1. "CWE-476: NULL Pointer Dereference". MITRE.
  2. ISO/IEC 9899, clause 6.3.2.3, paragraph 4.
  3. ISO/IEC 9899, clause 7.17, paragraph 3: NULL... which expands to an implementation-defined null pointer constant...
  4. ISO/IEC 9899, clause 6.3.2.3, paragraph 3.
  5. 5.0 5.1 ISO/IEC 9899, clause 6.5.3.2, paragraph 4, esp. footnote 87.
  6. 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.
  7. Stroustrup, Bjarne (March 2001). "Chapter 5:
    The const qualifier (§5.4) prevents accidental redefinition of NULL and ensures that NULL can 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.
  8. "CWE-476: NULL Pointer Dereference". MITRE.
  9. The Objective-C 2.0 Programming Language, section "Sending Messages to nil".
  10. OS X exploitable kernel NULL pointer dereference in AppleGraphicsDeviceControl
  11. 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.
  12. "Void-safety: Background, definition, and tools". Retrieved 2021-11-24.
  13. Bartosz Milewski. "SafeD – D Programming Language". Retrieved 17 July 2014.
  14. "Fearless Security: Memory Safety". Archived from the original on 8 November 2020. Retrieved 4 November 2020.
  15. Tony Hoare (2009-08-25). "Null References: The Billion Dollar Mistake". InfoQ.com.


स्रोत

श्रेणी:डेटा प्रकार