मैं आपके ध्यान में हाल ही में क्यू- इलेक्ट्रॉनिक पत्रिका में पौल-हेनिंग काम्प द्वारा पोस्ट का अनुवाद लाता हूं।

केन, डेनिस और ब्रायन गलत थे जब एनयूएल-पूर्ण पाठ तार का उपयोग करना चुनते हैं?

आईटी आधुनिक पश्चिमी अर्थव्यवस्था को उत्तेजित और कार्यान्वित करता है। तदनुसार, हम अक्सर आईटी त्रुटियों के साथ जुड़े भारी मात्रा में पैसे के बारे में सुर्खियों में देखते हैं। आईटी या CI [कंप्यूटर विज्ञान] के लिए सबसे महंगा समाधान क्या है?

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

सोनी (शायद) यह पता नहीं लगाना चाहता है कि अगर आप सुरक्षा पर थोड़ा ध्यान देते हैं तो किस तरह की गड़बड़ी होगी, इसलिए यह और झूठी बचत के अन्य उदाहरण योग्य नहीं हैं। एक अन्य उम्मीदवार गैरी किल्डल के बजाय अपने व्यक्तिगत कंप्यूटर के लिए ऑपरेटिंग सिस्टम प्रदाता के रूप में आईबीएम बिल गेट्स की पसंद होगा। इस निर्णय से नुकसान अभी भी ब्रेकनेक गति से जमा हो रहा है: स्टक्सनेट [लगभग]। प्रति। नेटवर्क वर्म] और ओओएक्सएमएल आईएसओ मानकीकरण प्रक्रिया की विकृति यह प्रदर्शित करती है कि कितनी दूर और व्यापक क्षति फैल सकती है। लेकिन यह आईटी या आईपी से जुड़ा फैसला नहीं था। जैसा कि वर्तमान में ज्ञात है, यह किडल द्वारा आईबीएम की गैर-प्रकटीकरण आवश्यकताओं को स्वीकार करने से इनकार करने के आधार पर एक व्यावसायिक निर्णय था।

MS-DOS के लिए अपनी स्वयं की निर्देशिका / फ़ाइल नाम सीमांकक का आविष्कार करने का निर्णय लेने के लिए एक और अधिक उपयुक्त उदाहरण होगा: बैकस्लैश (\) को फ़ॉरवर्ड स्लैश (/) के बजाय चुना गया था जो कि यूनिक्स या डॉट पर इस्तेमाल किया गया था जो उनके ऑपरेटिंग सिस्टम के लिए DEC का उपयोग करता था। । हालांकि वास्तविक क्षति अपेक्षाकृत मध्यम है, यह समाधान भी एक अच्छे उदाहरण के रूप में फिट नहीं है, क्योंकि यह वास्तविक समाधान नहीं था, यह एक सच्ची प्राथमिकता थी। IBM ने कमांड के झंडे के लिए एक स्लैश का उपयोग करने के लिए चुना, यूनिक्स की अनदेखी की और अवधि को फ़ाइल नाम और विस्तार के लिए विभाजक के रूप में उपयोग किया गया, जिससे DEC उदाहरण का पालन करना असंभव हो गया।

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

सबसे अच्छा उदाहरण मुझे मिल सकता है C / Unix / Posix में NUL- पूर्ण पाठ स्ट्रिंग्स का उपयोग कर रहा है। एक बहुत ही सरल विकल्प था: C को पता + लंबाई के ट्यूल के रूप में स्ट्रिंग्स का प्रतिनिधित्व करना चाहिए, या केवल एक पते के रूप में और किसी स्ट्रिंग के अंत में किसी प्रकार का जादू चरित्र (NUL) चिह्नित करना चाहिए? यह निर्णय था कि डायनेमिक तिकड़ी केन थॉम्पसन, डेनिस रिची और ब्रायन केर्निगन ने 70 के दशक की शुरुआत में बनाई थी, और वे किसी भी तरीके को चुनने के लिए स्वतंत्र थे। मुझे निर्णय का एक भी रिकॉर्ड नहीं मिला, जिसे मैं एक कमजोर उम्मीदवार के रूप में पहचानता हूं: मेरे पास कोई सबूत नहीं है कि यह निर्णय सचेत था।

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

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

हार्डवेयर विकास लागत

प्रारंभ में, यूनिक्स का हार्डवेयर और आदेशों के एक समूह [लगभग] के विकास पर बहुत कम प्रभाव था। प्रति। प्रोसेसर]। Z-80 और DEC VAX जैसे स्ट्रिंग्स में हेरफेर करने के निर्देश प्रदान करने वाले प्रोसेसर ने इसे बहुत अधिक सामान्य पते / ऑफसेट मॉडल का उपयोग करके किया। एक बार यूनिक्स और सी को समर्थन मिला, एनयूएल-पूर्ण तार अनुकूलन के लिए लक्ष्य बन गया। सीपीयू डेवलपर्स ने उनके साथ काम करने के लिए निर्देश जोड़ना शुरू कर दिया है। एक उदाहरण 1992 में आईबीएम द्वारा ES / 9000 520 पर आधारित प्रोसेसर के लिए लॉजिकल स्ट्रिंग असिस्ट निर्देश है।

सीपीयू में निर्देश जोड़ना सस्ता नहीं है और केवल तब होता है जब मूर्त और मात्रात्मक मौद्रिक कारण होते हैं।

प्रदर्शन लागत

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

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

एक उदाहरण FreeBSD में libc लाइब्रेरी है, जहाँ bcopy (3) / memcpy (3) कार्यान्वयन "अहस्ताक्षरित पूर्णांक" में टुकड़ों में यथासंभव अधिक से अधिक जानकारी ले जाता है: आमतौर पर 32 या 64 बिट्स, और फिर बाइट कॉपी के रूप में "किसी भी अनुगामी बाइट्स" को साफ़ करता है। टिप्पणियों में वर्णित है।

एनयूएल-टर्मिनेटेड स्ट्रिंग का उपयोग करते समय, एक बाइट से बड़े हिस्सों के साथ उस पर काम करने का प्रयास करने से एनयूएल चरित्र के बाद पात्रों तक पहुंच हो सकती है। यदि NUL वर्ण वर्चुअल मेमोरी पेज का अंतिम बाइट है और अगले पृष्ठ को परिभाषित नहीं किया गया है, तो यह "पेज नहीं मिला" ["पृष्ठ मौजूद नहीं"] त्रुटि के साथ एक प्रक्रिया क्रैश हो सकती है।

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

यदि हम पहले से स्ट्रिंग की लंबाई जानते हैं, तो सब कुछ अलग है।

संकलक विकास लागत

अक्सर कंपाइलर स्ट्रिंग्स के बारे में एक बात जानता है - उनकी लंबाई, खासकर जब स्ट्रिंग्स स्थिर होते हैं। यदि प्रोग्रामर स्रोत कोड में strcpy (3) का उपयोग करता है, तो भी कंपाइलर तेजी से मेम्ची (3) को कॉल करने की अनुमति देता है।

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

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

सुरक्षा लागत

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

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

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

फिर भी, कोई भी आश्चर्यचकित नहीं होता अगर यह पता चलता कि सोनी की समस्याएं बफर ओवरफ्लो या लाइन के अंत की गलत व्याख्या के साथ शुरू हुईं।

Slashdot Sensations को रोकना

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

दूसरे शब्दों में, केन, डेनिस और ब्रायन ने सब कुछ सही किया।

लेकिन इससे समस्या हल नहीं होती है

बहुत से लोगों के लिए, C की मृत्यु हो गई है, और $ {lang} के बदलते अल्पकालिक मूल्य के लिए $ {lang} भविष्य की भाषा है। वास्तव में, अन्य सभी भाषाएं प्रत्यक्ष या अप्रत्यक्ष रूप से पॉज़िक्स एपीआई और सी के एनयूएल-पूर्ण स्ट्रिंग्स के ऊपर बैठती हैं।

जब आपका जावा, पायथन, रूबी, या हास्केल प्रोग्राम एक फ़ाइल खोलता है, तो रनटाइम फ़ाइल नाम को खोलने के लिए एनयूएल-टर्मिनेटेड स्ट्रिंग के रूप में पास करता है (3); या जब यह एक IP पते पर queue.acm.org को कनवर्ट करता है, तो यह होस्ट नाम को NAD- टर्मिनेटेड स्ट्रिंग के रूप में getaddrinfo (3) के रूप में पास करता है। जब तक आप ऐसा करना जारी रखते हैं, आप पीडीपी / 11 पर अपना कार्यक्रम चलाते समय सभी फायदे को बरकरार रखेंगे, और किसी भी चीज पर चलने पर सभी नुकसान होंगे।

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

इस प्रकार, केन, डेनिस और ब्रायन के निर्णय की लागत जमा होती रहेगी, क्योंकि धूल लगभग सदियों से प्राचीन रोम में दफन है।

संदर्भ

1. कंप्यूटर व्यवसाय की समीक्षा। 1992. शीर्ष-अंत ES / 9000 के लिए विभाजन और Escon संवर्द्धन; http://www.cbronline.com/news/ibm_announcements_71
2. दृश्य। 2007. / //ib/libc/string/bcopy.c की सामग्री; http://svnweb.freebsd.org/base/head/lib/libc/string/bcopy.c?view=markup
3. विकिपीडिया। 2011. लाइफबोट स्केच; http://en.wikipedia.org/wiki/Lifeboat_sketch