बाउंडस चेकिंग

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

चूंकि प्रत्येक उपयोग के दौरान सीमा जांच करने में समय लग सकता है, इसलिए यह हमेशा नहीं किया जाता है। सीमा-जाँच उन्मूलन एक कंपाइलर अनुकूलन तकनीक है जो अनावश्यक सीमा जाँच को समाप्त करती है।

रेंज चेकिंग
रेंज जांच यह सुनिश्चित करने के लिए की जाने वाली जांच है कि कोई संख्या एक निश्चित सीमा के भीतर है; उदाहरण के लिए, यह सुनिश्चित करने के लिए कि 16-बिट पूर्णांक को सौंपा जाने वाला मान 16-बिट पूर्णांक की क्षमता के भीतर है (यानी अंकगणित अतिप्रवाह | रैप-अराउंड के खिलाफ जाँच)। यह बिल्कुल टाइप चेकिंग के समान नहीं है। अन्य सीमा जाँचें अधिक प्रतिबंधात्मक हो सकती हैं; उदाहरण के लिए, एक कैलेंडर माह की संख्या रखने के लिए एक चर को केवल 1 से 12 की सीमा को स्वीकार करने के लिए घोषित किया जा सकता है।

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

सूचकांक जाँच क्षमता वाली आरंभिक संकलित प्रोग्रामिंग भाषाओं में ALGOL 60, ALGOL 68 और पास्कल (प्रोग्रामिंग भाषा) के साथ-साथ BASIC जैसी व्याख्या की गई प्रोग्रामिंग भाषाएँ शामिल थीं।

कई प्रोग्रामिंग भाषाएं, जैसे सी (प्रोग्रामिंग भाषा), गति बढ़ाने के लिए कभी भी स्वचालित सीमा जांच नहीं करती हैं। हालाँकि, इससे एक-एक करके कई त्रुटियाँ और बफ़र ओवरफ़्लो पकड़ में नहीं आते हैं। कई प्रोग्रामर मानते हैं कि ये भाषाएँ तेजी से निष्पादन के लिए बहुत अधिक त्याग करती हैं। अपने 1980 के ट्यूरिंग पुरस्कार  व्याख्यान में, सी. ए. आर. होरे ने ALGOL 60 के डिज़ाइन में अपने अनुभव का वर्णन किया, एक ऐसी भाषा जिसमें सीमा जाँच शामिल थी, उन्होंने कहा:

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

रन टाइम चेकिंग को लागू करने वाली मुख्यधारा की भाषाओं में एडा (प्रोग्रामिंग भाषा), सी शार्प (प्रोग्रामिंग भाषा)|सी#, हास्केल (प्रोग्रामिंग भाषा), जावा (प्रोग्रामिंग भाषा), जावास्क्रिप्ट, लिस्प (प्रोग्रामिंग भाषा), पीएचपी, पायथन (प्रोग्रामिंग भाषा) शामिल हैं।, रूबी (प्रोग्रामिंग भाषा), रस्ट (प्रोग्रामिंग भाषा), और मूल दृश्य D (प्रोग्रामिंग भाषा) और OCaml भाषाओं में समय सीमा की जाँच होती है जो कंपाइलर स्विच के साथ सक्षम या अक्षम होती है। C++ में रन टाइम चेकिंग भाषा का हिस्सा नहीं है, बल्कि मानक टेम्पलेट लाइब्रेरी का हिस्सा है और एक कंपाइलर स्विच (_GLIBCXX_DEBUG=1 या _LIBCPP_DEBUG=1) के साथ सक्षम है। C# असुरक्षित क्षेत्रों का भी समर्थन करता है: कोड के अनुभाग जो (अन्य बातों के अलावा) दक्षता बढ़ाने के लिए सीमा जांच को अस्थायी रूप से निलंबित कर देते हैं। ये पूरे कार्यक्रम की सुरक्षा से समझौता किए बिना छोटी समय-महत्वपूर्ण बाधाओं को तेज करने के लिए उपयोगी हैं।

JS++ प्रोग्रामिंग भाषा मौजूदा प्रकारों का उपयोग करके यह विश्लेषण करने में सक्षम है कि क्या कोई सरणी सूचकांक या मानचित्र कुंजी संकलन समय पर सीमा से बाहर है, जो एक नाममात्र प्रकार की प्रणाली है जो यह बताती है कि सूचकांक या कुंजी सीमा के भीतर है या सीमा से बाहर है। और कोड जनरेशन का मार्गदर्शन करता है। मौजूदा प्रकारों को संकलन समय में केवल 1ms ओवरहेड जोड़ने के लिए दिखाया गया है।

हार्डवेयर सीमा जाँच
यदि जाँच सॉफ़्टवेयर में की जाती है तो सीमा जाँच द्वारा जोड़ी गई सुरक्षा में आवश्यक रूप से CPU समय खर्च होता है; हालाँकि, यदि जाँच हार्डवेयर द्वारा की जा सकती है, तो बिना किसी रनटाइम लागत के सुरक्षा निःशुल्क प्रदान की जा सकती है। हार्डवेयर सीमा जाँच वाली एक प्रारंभिक प्रणाली 1974 में घोषित आईसीएल 2900 सीरीज मेनफ्रेम थी। VAX कंप्यूटर में ऐरे इंडेक्स जाँच के लिए एक INDEX असेंबली निर्देश होता है जिसमें छह ऑपरेंड लगते हैं, जिनमें से सभी किसी भी VAX एड्रेसिंग मोड का उपयोग कर सकते हैं। B6500 और इसी तरह के बरोज़ कॉर्पोरेशन कंप्यूटरों ने हार्डवेयर के माध्यम से बाउंड चेकिंग की, भले ही मशीन कोड का उत्पादन करने के लिए किसी भी कंप्यूटर भाषा को संकलित किया गया हो। सीमित संख्या में बाद के CPU  में सीमाओं की जांच के लिए विशेष निर्देश हैं, उदाहरण के लिए, मोटोरोला 68000#इंटरप्ट्स श्रृंखला पर सीएचके2 निर्देश।

ऐरे और बफर एक्सेस की सुरक्षा सुनिश्चित करने के लिए x86 की अंतर्निहित वर्चुअल मेमोरी प्रबंधन इकाई का उपयोग करने के तरीकों के संबंध में कम से कम 2005 से अनुसंधान चल रहा है। 2015 में इंटेल ने अपने स्काईलेक (माइक्रोआर्किटेक्चर) प्रोसेसर आर्किटेक्चर में इंटेल एमपीएक्स एक्सटेंशन प्रदान किया जो सीपीयू रजिस्टर और मेमोरी में टेबल में सीमाओं को संग्रहीत करता है। 2017 की शुरुआत में कम से कम जीसीसी एमपीएक्स एक्सटेंशन का समर्थन करता है।

यह भी देखें

 * गतिशील कोड विश्लेषण
 * रनटाइम त्रुटि का पता लगाना
 * स्थैतिक कार्यक्रम विश्लेषण

बाहरी संबंध

 * “On The Advantages Of Tagged Architecture”, IEEE Transactions On Computers, Volume C-22, Number 7, July, 1973.
 * “The Emperor’s Old Clothes ”, 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
 * 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
 * libc++ 11.0 documentation Debug Mode