बाउंडस चेकिंग: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Short description|In programming, detecting whether a variable is within given bounds before use}} | {{Short description|In programming, detecting whether a variable is within given bounds before use}} | ||
[[कंप्यूटर प्रोग्रामिंग]] में, '''बाउंडस चेकिंग''' (सीमा की जाँच) यह ज्ञात करने की एक विधि है कि क्या कोई चर उपयोग करने से पहले कुछ | [[कंप्यूटर प्रोग्रामिंग]] में, '''बाउंडस चेकिंग''' (सीमा की जाँच) यह ज्ञात करने की एक विधि है कि क्या कोई चर उपयोग करने से पहले कुछ बाउंडस के अन्दर है। इसका उपयोग सामान्यतः यह सुनिश्चित करने के लिए किया जाता है कि कोई संख्या किसी दिए गए प्रकार (रेंज चेकिंग) में फिट होती है, या कि ऐरे इंडेक्स के रूप में उपयोग किया जा रहा एक चर ऐरे (इंडेक्स चेकिंग) की बाउंडस के भीतर है। विफल बाउंडस चेकिंग के परिणामस्वरूप सामान्यतः कुछ प्रकार के अपवाद संकेत उत्पन्न होते हैं। | ||
क्योंकि प्रत्येक उपयोग के लिए बाउंडस चेकिंग में समय लग सकता है, यह हमेशा नहीं किया जाता है। बाउंडस-जांच उन्मूलन कंपाइलर अनुकूलन तकनीक है जो अनावश्यक बाउंडस चेकिंग को समाप्त करती है। | |||
==रेंज चेकिंग== | ==रेंज चेकिंग== | ||
रेंज चेकिंग एक जांच है जो यह सुनिश्चित करती है कि कोई संख्या एक निश्चित | रेंज चेकिंग एक जांच है जो यह सुनिश्चित करती है कि कोई संख्या एक निश्चित बाउंडस के भीतर है; उदाहरण के लिए, यह सुनिश्चित करने के लिए कि 16-बिट पूर्णांक को सौंपा जाने वाला मान 16-बिट पूर्णांक की क्षमता के भीतर है (अर्थात रैप-अराउंड के विरुद्ध जाँच करना)। यह टाइप चेकिंग के बिल्कुल समान नहीं है। अन्य श्रेणी की जाँचें अधिक प्रतिबंधात्मक हो सकती हैं; उदाहरण के लिए, कैलेंडर माह की संख्या रखने के लिए एकचर को केवल 1 से 12 तक की बाउंडस को स्वीकार करने के लिए घोषित किया जा सकता है। | ||
==इंडेक्स चेकिंग ( | ==इंडेक्स चेकिंग (इंडेक्स चेकिंग)== | ||
इंडेक्स चेकिंग का अर्थ है कि, किसी ऐरे को अनुक्रमित करने वाले सभी अभिव्यक्तियों में, इंडेक्स मान को ऐरे की बाउंडस के विरुद्ध जाँचा जाता है (जो कि ऐरे परिभाषित होने पर स्थापित किए गए थे), और यदि इंडेक्स बाउंडस से बाहर है, तो आगे का निष्पादन किसी प्रकार की त्रुटि के कारण निलंबित हो जाता है। चूँकि किसी ऐरे की बाउंडस के बाहर किसी मान को पढ़ने या विशेष रूप से लिखने से प्रोग्राम दोषपूर्ण हो सकता है या क्रैश हो सकता है या सुरक्षा कमजोरियाँ सक्षम हो सकती हैं (बफ़र ओवरफ़्लो देखें), इंडेक्स चेकिंग कई उच्च-स्तरीय लैंग्वेज का भाग है। | |||
इंडेक्स-चेकिंग क्षमता वाली प्रारंभिक संकलित प्रोग्रामिंग | इंडेक्स-चेकिंग क्षमता वाली प्रारंभिक संकलित प्रोग्रामिंग लैंग्वेज में [[ALGOL 60]], [[ALGOL 68]] और [[पास्कल (प्रोग्रामिंग भाषा)|पास्कल]] के साथ-साथ [[BASIC]] जैसी व्याख्या की गई प्रोग्रामिंग लैंग्वेज सम्मिलित थीं। | ||
कई प्रोग्रामिंग | कई प्रोग्रामिंग लैंग्वेज, जैसे C, गति बढ़ाने के लिए कभी भी स्वचालित बाउंडस चेकिंग नहीं करती हैं। हालाँकि, यह कई आवर्ती एरर और बफ़र ओवरफ़्लो को नहीं पकड़ता है। कई प्रोग्रामर का मानना है कि ये लैंग्वेज त्वरित निष्पादन के लिए बहुत अधिक त्याग करती हैं।<ref>{{Cite book |doi=10.1109/DISCEX.2000.821514|chapter=Buffer overflows: Attacks and defenses for the vulnerability of the decade|title=कार्यवाही DARPA सूचना उत्तरजीविता सम्मेलन और प्रदर्शनी। डिस्केक्स'00|volume=2|pages=119–129|year=1999|last1=Cowan|first1=C|last2=Wagle|first2=F|last3=Calton Pu|last4=Beattie|first4=S|last5=Walpole|first5=J|isbn=978-0-7695-0490-2|s2cid=167759976}}</ref> अपने 1980 के ट्यूरिंग अवार्ड व्याख्यान में, सी. ए. आर. होरे ने ALGOL 60 के डिजाइन में अपने अनुभव का वर्णन किया, ऐसी लैंग्वेज जिसमें बाउंडस चेकिंग सम्मिलित थी, उन्होंने कहा:<blockquote>इस सिद्धांत का एक परिणाम यह है कि प्रत्येक सबस्क्रिप्टेड वेरिएबल की प्रत्येक सबस्क्रिप्ट की प्रत्येक घटना को प्रत्येक अवसर पर ऐरे के ऊपरी और निचले दोनों घोषित बाउंडस के विरुद्ध रन टाइम पर जांचा गया था। कई वर्षों बाद हमने अपने ग्राहकों से पूछा कि क्या वे चाहते हैं कि हम उत्पादन संचालन की दक्षता के हित में इन चेकों को बंद करने का विकल्प प्रदान करें। सर्वसम्मति से, उन्होंने हमसे ऐसा न करने का आग्रह किया - वे पहले से ही जानते थे कि उत्पादन संचालन में कितनी बार सबस्क्रिप्ट एरर होती हैं, जहाँ उनका पता लगाने में विफलता विनाशकारी हो सकती है। मैं भय और भय के साथ नोट करता हूं कि 1980 में भी, लैंग्वेज डिजाइनरों और उपयोगकर्ताओं ने यह सबक नहीं सीखा है। इंजीनियरिंग की किसी भी सम्मानजनक शाखा में, ऐसी प्राथमिक सावधानियों का पालन करने में विफलता लंबे समय तक नियम के विरूद्ध होती है।</blockquote>रन टाइम चेकिंग लागू करने वाली मेनस्ट्रीम की लैंग्वेज में Ada, C#, [[हास्केल (प्रोग्रामिंग भाषा)|हास्केल]], [[जावा (प्रोग्रामिंग भाषा)|जावा]], [[जावास्क्रिप्ट]], [[लिस्प (प्रोग्रामिंग भाषा)|लिस्प]], [[पीएचपी]], [[पायथन (प्रोग्रामिंग भाषा)|पायथन]], रूबी, रस्ट और विज़ुअल बेसिक सम्मिलित हैं। D और [[OCaml]] लैंग्वेज में समय बाउंडस जांच चल रही है जो कंपाइलर स्विच के साथ सक्षम या अक्षम है। [[C++]] में रन टाइम चेकिंग लैंग्वेज का हिस्सा नहीं है, बल्कि STL का हिस्सा है और कंपाइलर स्विच (_GLIBCXX_DEBUG=1 या _LIBCPP_DEBUG=1) के साथ सक्षम है। C# असुरक्षित क्षेत्रों का भी समर्थन करता है: कोड के अनुभाग जो (अन्य बातों के अतिरिक्त) दक्षता बढ़ाने के लिए अस्थायी रूप से बाउंडस जांच को निलंबित कर देते हैं। ये पूरे प्रोग्राम की सुरक्षा से समझौता किए बिना समय-महत्वपूर्ण छोटी बाधाओं को तेज करने के लिए उपयोगी हैं। | ||
[[JS++]] प्रोग्रामिंग लैंग्वेज यह विश्लेषण करने में सक्षम है कि उपस्थित प्रकारों का उपयोग करके संकलन समय पर कोई ऐरे अनुक्रमणिका या मानचित्र की बाउंडस से बाहर है या नहीं, जो नाममात्र प्रकार है जो यह बताता है कि इंडेक्स या कुंजी बाउंडस के भीतर है या बाउंडस से बाहर है और कोड निर्माण का मार्गदर्शन करता है। उपस्थित प्रकारों को संकलन समय में केवल 1 एमएस ओवरहेड जोड़ने के लिए दिखाया गया है।<ref>{{Cite web | url=https://www.onux.com/jspp/blog/jspp-0-9-0-efficient-compile-time-analysis-of-out-of-bounds-errors/ | archive-url=https://web.archive.org/web/20190112060200/https://www.onux.com/jspp/blog/jspp-0-9-0-efficient-compile-time-analysis-of-out-of-bounds-errors/| archive-date=2019-01-12| title=JS++ 0.9.0: Efficient Compile Time Analysis of Out-of-Bounds Errors – JS++ Blog}}</ref> | |||
[[JS++]] प्रोग्रामिंग | |||
== हार्डवेयर बाउंडस चेकिंग == | == हार्डवेयर बाउंडस चेकिंग == | ||
यदि सॉफ़्टवेयर में जाँच की जाती है तो बाउंडस चेकिंग द्वारा जोड़ी गई सुरक्षा में आवश्यक रूप से CPU समय खर्च होता है; हालाँकि, यदि जाँच हार्डवेयर द्वारा की जा सकती है, तो सुरक्षा बिना किसी रनटाइम लागत के "मुफ़्त" प्रदान की जा सकती है। 1974 में घोषित आईसीएल 2900 सीरीज मेनफ्रेम हार्डवेयर | यदि सॉफ़्टवेयर में जाँच की जाती है तो बाउंडस चेकिंग द्वारा जोड़ी गई सुरक्षा में आवश्यक रूप से CPU समय खर्च होता है; हालाँकि, यदि जाँच हार्डवेयर द्वारा की जा सकती है, तो सुरक्षा बिना किसी रनटाइम लागत के "मुफ़्त" प्रदान की जा सकती है। 1974 में घोषित आईसीएल 2900 सीरीज मेनफ्रेम हार्डवेयर बाउंडस चेकिंग करने वाली प्रारंभिक प्रणाली थी।<ref>{{cite book |pages=17, 77 |url=http://www.fujitsu.com/uk/Images/icl-2900-series-by-jk-buckle.pdf |title=The ICL 2900 Series |author=J. K. Buckle |publisher=Macmillan Computer Science Series |year=1978 |isbn=978-0-333-21917-1 |access-date=20 April 2018 |archive-date=20 April 2018 |archive-url=https://web.archive.org/web/20180420203006/http://www.fujitsu.com/uk/Images/icl-2900-series-by-jk-buckle.pdf |url-status=dead }}</ref> [[VAX]] कंप्यूटर में ऐरे इंडेक्स चेकिंग के लिए INDEX असेंबली इंस्ट्रक्शन होता है, जिसमें छह ऑपरेंड लगते हैं, जिनमें से सभी किसी भी VAX एड्रेसिंग मोड का उपयोग कर सकते हैं। B6500 और इसी तरह के बरोज़ कंप्यूटरों ने हार्डवेयर के माध्यम से बाउंड चेकिंग की, भले ही मशीन कोड का उत्पादन करने के लिए किसी भी कंप्यूटर लैंग्वेज को संकलित किया गया हो। सीमित संख्या में बाद के सीपीयू में बाउंडस चेकिंग के लिए विशेष निर्देश हैं, उदाहरण के लिए, मोटोरोला 68000 श्रृंखला पर CHK2 निर्देश हैं। | ||
ऐरे और बफर एक्सेस की सुरक्षा सुनिश्चित करने के लिए x86 की अंतर्निहित वर्चुअल मेमोरी प्रबंधन इकाई का उपयोग करने के तरीकों के संबंध में कम से कम 2005 से शोध चल रहा है।<ref>{{Cite book | doi=10.1109/DSN.2005.25| chapter=Checking Array Bound Violation Using Segmentation Hardware| title=2005 International Conference on Dependable Systems and Networks (DSN'05)| pages=388–397| year=2005| last1=Lap-Chung Lam| last2=Tzi-Cker Chiueh| isbn=0-7695-2282-3| s2cid=6278708}}</ref> 2015 में इंटेल ने अपने [[स्काईलेक (माइक्रोआर्किटेक्चर)|स्काईलेक]] प्रोसेसर आर्किटेक्चर में अपने [[इंटेल एमपीएक्स]] एक्सटेंशन प्रदान किए जो सीपीयू रजिस्टर और मेमोरी में टेबल में | ऐरे और बफर एक्सेस की सुरक्षा सुनिश्चित करने के लिए x86 की अंतर्निहित वर्चुअल मेमोरी प्रबंधन इकाई का उपयोग करने के तरीकों के संबंध में कम से कम 2005 से शोध चल रहा है।<ref>{{Cite book | doi=10.1109/DSN.2005.25| chapter=Checking Array Bound Violation Using Segmentation Hardware| title=2005 International Conference on Dependable Systems and Networks (DSN'05)| pages=388–397| year=2005| last1=Lap-Chung Lam| last2=Tzi-Cker Chiueh| isbn=0-7695-2282-3| s2cid=6278708}}</ref> 2015 में इंटेल ने अपने [[स्काईलेक (माइक्रोआर्किटेक्चर)|स्काईलेक]] प्रोसेसर आर्किटेक्चर में अपने [[इंटेल एमपीएक्स]] एक्सटेंशन प्रदान किए जो सीपीयू रजिस्टर और मेमोरी में टेबल में बाउंडस को संग्रहीत करते हैं। 2017 के प्रारम्भ में कम से कम GCC MPX एक्सटेंशन का समर्थन करता है। | ||
== यह भी देखें == | == यह भी देखें == | ||
Revision as of 17:18, 12 August 2023
कंप्यूटर प्रोग्रामिंग में, बाउंडस चेकिंग (सीमा की जाँच) यह ज्ञात करने की एक विधि है कि क्या कोई चर उपयोग करने से पहले कुछ बाउंडस के अन्दर है। इसका उपयोग सामान्यतः यह सुनिश्चित करने के लिए किया जाता है कि कोई संख्या किसी दिए गए प्रकार (रेंज चेकिंग) में फिट होती है, या कि ऐरे इंडेक्स के रूप में उपयोग किया जा रहा एक चर ऐरे (इंडेक्स चेकिंग) की बाउंडस के भीतर है। विफल बाउंडस चेकिंग के परिणामस्वरूप सामान्यतः कुछ प्रकार के अपवाद संकेत उत्पन्न होते हैं।
क्योंकि प्रत्येक उपयोग के लिए बाउंडस चेकिंग में समय लग सकता है, यह हमेशा नहीं किया जाता है। बाउंडस-जांच उन्मूलन कंपाइलर अनुकूलन तकनीक है जो अनावश्यक बाउंडस चेकिंग को समाप्त करती है।
रेंज चेकिंग
रेंज चेकिंग एक जांच है जो यह सुनिश्चित करती है कि कोई संख्या एक निश्चित बाउंडस के भीतर है; उदाहरण के लिए, यह सुनिश्चित करने के लिए कि 16-बिट पूर्णांक को सौंपा जाने वाला मान 16-बिट पूर्णांक की क्षमता के भीतर है (अर्थात रैप-अराउंड के विरुद्ध जाँच करना)। यह टाइप चेकिंग के बिल्कुल समान नहीं है। अन्य श्रेणी की जाँचें अधिक प्रतिबंधात्मक हो सकती हैं; उदाहरण के लिए, कैलेंडर माह की संख्या रखने के लिए एकचर को केवल 1 से 12 तक की बाउंडस को स्वीकार करने के लिए घोषित किया जा सकता है।
इंडेक्स चेकिंग (इंडेक्स चेकिंग)
इंडेक्स चेकिंग का अर्थ है कि, किसी ऐरे को अनुक्रमित करने वाले सभी अभिव्यक्तियों में, इंडेक्स मान को ऐरे की बाउंडस के विरुद्ध जाँचा जाता है (जो कि ऐरे परिभाषित होने पर स्थापित किए गए थे), और यदि इंडेक्स बाउंडस से बाहर है, तो आगे का निष्पादन किसी प्रकार की त्रुटि के कारण निलंबित हो जाता है। चूँकि किसी ऐरे की बाउंडस के बाहर किसी मान को पढ़ने या विशेष रूप से लिखने से प्रोग्राम दोषपूर्ण हो सकता है या क्रैश हो सकता है या सुरक्षा कमजोरियाँ सक्षम हो सकती हैं (बफ़र ओवरफ़्लो देखें), इंडेक्स चेकिंग कई उच्च-स्तरीय लैंग्वेज का भाग है।
इंडेक्स-चेकिंग क्षमता वाली प्रारंभिक संकलित प्रोग्रामिंग लैंग्वेज में ALGOL 60, ALGOL 68 और पास्कल के साथ-साथ BASIC जैसी व्याख्या की गई प्रोग्रामिंग लैंग्वेज सम्मिलित थीं।
कई प्रोग्रामिंग लैंग्वेज, जैसे C, गति बढ़ाने के लिए कभी भी स्वचालित बाउंडस चेकिंग नहीं करती हैं। हालाँकि, यह कई आवर्ती एरर और बफ़र ओवरफ़्लो को नहीं पकड़ता है। कई प्रोग्रामर का मानना है कि ये लैंग्वेज त्वरित निष्पादन के लिए बहुत अधिक त्याग करती हैं।[1] अपने 1980 के ट्यूरिंग अवार्ड व्याख्यान में, सी. ए. आर. होरे ने ALGOL 60 के डिजाइन में अपने अनुभव का वर्णन किया, ऐसी लैंग्वेज जिसमें बाउंडस चेकिंग सम्मिलित थी, उन्होंने कहा:
इस सिद्धांत का एक परिणाम यह है कि प्रत्येक सबस्क्रिप्टेड वेरिएबल की प्रत्येक सबस्क्रिप्ट की प्रत्येक घटना को प्रत्येक अवसर पर ऐरे के ऊपरी और निचले दोनों घोषित बाउंडस के विरुद्ध रन टाइम पर जांचा गया था। कई वर्षों बाद हमने अपने ग्राहकों से पूछा कि क्या वे चाहते हैं कि हम उत्पादन संचालन की दक्षता के हित में इन चेकों को बंद करने का विकल्प प्रदान करें। सर्वसम्मति से, उन्होंने हमसे ऐसा न करने का आग्रह किया - वे पहले से ही जानते थे कि उत्पादन संचालन में कितनी बार सबस्क्रिप्ट एरर होती हैं, जहाँ उनका पता लगाने में विफलता विनाशकारी हो सकती है। मैं भय और भय के साथ नोट करता हूं कि 1980 में भी, लैंग्वेज डिजाइनरों और उपयोगकर्ताओं ने यह सबक नहीं सीखा है। इंजीनियरिंग की किसी भी सम्मानजनक शाखा में, ऐसी प्राथमिक सावधानियों का पालन करने में विफलता लंबे समय तक नियम के विरूद्ध होती है।
रन टाइम चेकिंग लागू करने वाली मेनस्ट्रीम की लैंग्वेज में Ada, C#, हास्केल, जावा, जावास्क्रिप्ट, लिस्प, पीएचपी, पायथन, रूबी, रस्ट और विज़ुअल बेसिक सम्मिलित हैं। D और OCaml लैंग्वेज में समय बाउंडस जांच चल रही है जो कंपाइलर स्विच के साथ सक्षम या अक्षम है। C++ में रन टाइम चेकिंग लैंग्वेज का हिस्सा नहीं है, बल्कि STL का हिस्सा है और कंपाइलर स्विच (_GLIBCXX_DEBUG=1 या _LIBCPP_DEBUG=1) के साथ सक्षम है। C# असुरक्षित क्षेत्रों का भी समर्थन करता है: कोड के अनुभाग जो (अन्य बातों के अतिरिक्त) दक्षता बढ़ाने के लिए अस्थायी रूप से बाउंडस जांच को निलंबित कर देते हैं। ये पूरे प्रोग्राम की सुरक्षा से समझौता किए बिना समय-महत्वपूर्ण छोटी बाधाओं को तेज करने के लिए उपयोगी हैं।
JS++ प्रोग्रामिंग लैंग्वेज यह विश्लेषण करने में सक्षम है कि उपस्थित प्रकारों का उपयोग करके संकलन समय पर कोई ऐरे अनुक्रमणिका या मानचित्र की बाउंडस से बाहर है या नहीं, जो नाममात्र प्रकार है जो यह बताता है कि इंडेक्स या कुंजी बाउंडस के भीतर है या बाउंडस से बाहर है और कोड निर्माण का मार्गदर्शन करता है। उपस्थित प्रकारों को संकलन समय में केवल 1 एमएस ओवरहेड जोड़ने के लिए दिखाया गया है।[2]
हार्डवेयर बाउंडस चेकिंग
यदि सॉफ़्टवेयर में जाँच की जाती है तो बाउंडस चेकिंग द्वारा जोड़ी गई सुरक्षा में आवश्यक रूप से CPU समय खर्च होता है; हालाँकि, यदि जाँच हार्डवेयर द्वारा की जा सकती है, तो सुरक्षा बिना किसी रनटाइम लागत के "मुफ़्त" प्रदान की जा सकती है। 1974 में घोषित आईसीएल 2900 सीरीज मेनफ्रेम हार्डवेयर बाउंडस चेकिंग करने वाली प्रारंभिक प्रणाली थी।[3] VAX कंप्यूटर में ऐरे इंडेक्स चेकिंग के लिए INDEX असेंबली इंस्ट्रक्शन होता है, जिसमें छह ऑपरेंड लगते हैं, जिनमें से सभी किसी भी VAX एड्रेसिंग मोड का उपयोग कर सकते हैं। B6500 और इसी तरह के बरोज़ कंप्यूटरों ने हार्डवेयर के माध्यम से बाउंड चेकिंग की, भले ही मशीन कोड का उत्पादन करने के लिए किसी भी कंप्यूटर लैंग्वेज को संकलित किया गया हो। सीमित संख्या में बाद के सीपीयू में बाउंडस चेकिंग के लिए विशेष निर्देश हैं, उदाहरण के लिए, मोटोरोला 68000 श्रृंखला पर CHK2 निर्देश हैं।
ऐरे और बफर एक्सेस की सुरक्षा सुनिश्चित करने के लिए x86 की अंतर्निहित वर्चुअल मेमोरी प्रबंधन इकाई का उपयोग करने के तरीकों के संबंध में कम से कम 2005 से शोध चल रहा है।[4] 2015 में इंटेल ने अपने स्काईलेक प्रोसेसर आर्किटेक्चर में अपने इंटेल एमपीएक्स एक्सटेंशन प्रदान किए जो सीपीयू रजिस्टर और मेमोरी में टेबल में बाउंडस को संग्रहीत करते हैं। 2017 के प्रारम्भ में कम से कम GCC MPX एक्सटेंशन का समर्थन करता है।
यह भी देखें
- डायनामिक कोड एनालिसिस
- रनटाइम एरर डिटेक्शन
- स्टेटिक कोड एनालिसिस
संदर्भ
- ↑ Cowan, C; Wagle, F; Calton Pu; Beattie, S; Walpole, J (1999). "Buffer overflows: Attacks and defenses for the vulnerability of the decade". कार्यवाही DARPA सूचना उत्तरजीविता सम्मेलन और प्रदर्शनी। डिस्केक्स'00. Vol. 2. pp. 119–129. doi:10.1109/DISCEX.2000.821514. ISBN 978-0-7695-0490-2. S2CID 167759976.
- ↑ "JS++ 0.9.0: Efficient Compile Time Analysis of Out-of-Bounds Errors – JS++ Blog". Archived from the original on 2019-01-12.
- ↑ J. K. Buckle (1978). The ICL 2900 Series (PDF). Macmillan Computer Science Series. pp. 17, 77. ISBN 978-0-333-21917-1. Archived from the original (PDF) on 20 April 2018. Retrieved 20 April 2018.
- ↑ Lap-Chung Lam; Tzi-Cker Chiueh (2005). "Checking Array Bound Violation Using Segmentation Hardware". 2005 International Conference on Dependable Systems and Networks (DSN'05). pp. 388–397. doi:10.1109/DSN.2005.25. ISBN 0-7695-2282-3. S2CID 6278708.
बाहरी संबंध
- “On The Advantages Of Tagged Architecture”, IEEE Transactions On Computers, Volume C-22, Number 7, July, 1973.
- “The Emperor’s Old Clothes Archived 2017-10-02 at the Wayback Machine”, The 1980 ACM Turing Award Lecture, CACM volume 24 number 2, February 1981, pp 75–83.
- “Bcc: Runtime checking for C programs”, Samuel C. Kendall, Proceedings of the USENIX Summer 1983 Conference.
- “Bounds Checking for C”, Richard Jones and Paul Kelly, Imperial College, July 1995.
- “ClearPath Enterprise Servers MCP Security Overview”, Unisys, April 2006.
- “Secure Virtual Architecture: A Safe Execution Environment for Commodity Operating Systems”, John Criswell, Andrew Lenharth, Dinakar Dhurjati, Vikram Adve, SOSP'07 21st ACM Symposium on Operating Systems Principles, 2007.
- “Fail-Safe C”, Yutaka Oiwa. Implementation of the Memory-safe Full ANSI-C Compiler. ACM SIGPLAN Conference on Programing Language Design and Implementations (PLDI2009), June 2009.
- “address-sanitizer”, Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov, Kostya Serebryany, Evgeniy Stepanov, Dmitriy Vyukov, LLVM Dev Meeting, November 18, 2011.
- Safe C Library of Bounded APIs
- "The Safe C Library". Dr. Dobb's Journal. February 20, 2009. Archived from the original on December 2, 2013. Retrieved November 13, 2012.
- Safe C API—Concise solution of buffer overflow, The OWASP Foundation, OWASP AppSec, Beijing 2011
- The GNU C++ Library Manual Macros
- libc++ 11.0 documentation Debug Mode
