😲 🤣 🧒🏿 एक जासूस खेलना चाहते हैं? आधी रात के कमांडर से एक फंक्शन में बग का पता लगाएं 👩🏻‍🤝‍👨🏾 🔥 📏

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

एक उपयोगकर्ता ने हमें दूसरे दिन एक ईमेल भेजा, जिसमें पूछा गया था कि वह फ़ंक्शन EatWhitespace (नीचे कोड देखें) पर चेतावनी क्यों दे रहा था। यह सवाल उतना तुच्छ नहीं है जितना यह लग सकता है। इस कोड में क्या गलत है, यह जानने की कोशिश करें।

static int EatWhitespace (FILE * InFile) /* ----------------------------------------------------------------------- ** * Scan past whitespace (see ctype(3C)) and return the first non-whitespace * character, or newline, or EOF. * * Input: InFile - Input source. * * Output: The next non-whitespace character in the input stream. * * Notes: Because the config files use a line-oriented grammar, we * explicitly exclude the newline character from the list of * whitespace characters. * - Note that both EOF (-1) and the nul character ('\0') are * considered end-of-file markers. * * ----------------------------------------------------------------------- ** */ { int c; for (c = getc (InFile); isspace (c) && ('\n' != c); c = getc (InFile)) ; return (c); } /* EatWhitespace */

जैसा कि आप देख सकते हैं, EatWhitespace एक छोटा कार्य है; इसका शरीर इस पर टिप्पणी से भी छोटा है :)। अब, आइए कुछ विवरण देखें।

यहाँ फ़ंक्शन getc का वर्णन है:

 int getc ( FILE * stream );

निर्दिष्ट स्ट्रीम की आंतरिक फ़ाइल स्थिति संकेतक द्वारा वर्तमान में निर्दिष्ट वर्ण लौटाता है। आंतरिक फ़ाइल पोजिशन इंडिकेटर तब अगले वर्ण के लिए उन्नत होता है। यदि स्ट्रीम कॉल करने पर अंतिम फ़ाइल में है, तो फ़ंक्शन EOF को लौटाता है और स्ट्रीम के लिए एंड-ऑफ-फ़ाइल संकेतक सेट करता है। यदि कोई पठन त्रुटि होती है, तो फ़ंक्शन ईओएफ लौटता है और स्ट्रीम (फेरर) के लिए त्रुटि संकेतक सेट करता है।

और यहाँ फ़ंक्शन का विवरण है:

 int isspace( int ch );

जाँचता है कि क्या दिया गया पात्र वर्तमान में स्थापित सी लोकेल द्वारा वर्गीकृत एक व्हाट्सएप चरित्र है। डिफ़ॉल्ट लोकेल में, व्हाट्सएप वर्ण निम्नलिखित हैं:

अंतरिक्ष (0x20, '');
फार्म फ़ीड (0x0c, '\ f');
लाइन फीड LF (0x0a, '\ n');
गाड़ी वापसी CR (0x0d, '\ r');
क्षैतिज टैब (0x09, '\ t');
ऊर्ध्वाधर टैब (0x0b, '\ v')।

वापसी मूल्य यदि चरित्र एक व्हाट्सएप चरित्र है तो गैर-शून्य मान; शून्य अन्यथा।

EatWhitespace फ़ंक्शन को लाइन फ़ीड '\ n' को छोड़कर सभी व्हाट्सएप वर्णों को छोड़ने की उम्मीद है। जब यह फ़ाइल के अंत (EOF) का सामना करता है, तो फ़ंक्शन फ़ाइल से पढ़ना भी बंद कर देगा।

अब जब कि तुम सब जानते हो, तो बग को खोजने की कोशिश करो!

नीचे दिए गए दो यूनिकॉर्न सुनिश्चित करेंगे कि आप गलती से टिप्पणी पर नज़र न डालें।

चित्रा 1. बग खोज के लिए समय। यूनिकॉर्न इंतजार कर रहे हैं।

चित्रा 1. बग खोज के लिए समय। यूनिकॉर्न इंतजार कर रहे हैं।

फिर भी नसीब नहीं?

ठीक है, आप देखते हैं, यह इसलिए है क्योंकि हमने आपसे आइस्पेस के बारे में झूठ बोला है। Bwa-हा-हा! यह एक मानक कार्य नहीं है - यह एक कस्टम मैक्रो है। हाँ, हम बदमाश हैं और हम आपको भ्रमित कर रहे हैं।

चित्र 2. आइकॉन के बारे में यूनिकॉर्न भ्रमित करने वाले पाठक।

चित्र 2. आइकॉन के बारे में यूनिकॉर्न भ्रमित करने वाले पाठक।

यह हम या हमारे गेंडा को दोष देने के लिए नहीं है, ज़ाहिर है। सभी भ्रम के लिए दोष GNU मिडनाइट कमांडर परियोजना के लेखकों के साथ है, जिन्होंने फ़ाइल charset.h में आइसस्पेस के अपने कार्यान्वयन को बनाया:

 #ifdef isspace #undef isspace #endif .... #define isspace(c) ((c)==' ' || (c) == '\t')

इस मैक्रो के साथ, लेखकों ने अन्य डेवलपर्स को भ्रमित किया। कोड इस धारणा के तहत लिखा गया था कि आइसस्पेस एक मानक फ़ंक्शन है, जो कि गाड़ी वापसी (0x0d, '\ r') को एक व्हाट्सएप चरित्र मानता है।

कस्टम मैक्रो, अपनी बारी में, केवल स्थान और टैब वर्णों को व्हॉट्सएप वर्ण मानता है। आइए उस मैक्रो को प्रतिस्थापित करें और देखें कि क्या होता है।

 for (c = getc (InFile); ((c)==' ' || (c) == '\t') && ('\n' != c); c = getc (InFile))

('\ N'! = C) उपप्रकार अनावश्यक (निरर्थक) है क्योंकि यह हमेशा सत्य का मूल्यांकन करेगा। पीवीएस-स्टूडियो आपको चेतावनी देकर आउटपुट के बारे में चेतावनी देता है:

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: ('\ n'! = C)। params.c 136।

इसे स्पष्ट करने के लिए, आइए 3 संभावित परिणामों की जाँच करें:

फ़ाइल के अंत तक पहुँच गया। EOF एक स्थान या टैब वर्ण नहीं है। शॉर्ट सर्किट मूल्यांकन के कारण ('\ n'! = C) सब-डेप्रिसिएशन का मूल्यांकन नहीं किया जाता है । पाश समाप्त हो जाता है।
फ़ंक्शन ने कुछ ऐसे चरित्र पढ़े हैं जो कोई स्थान या टैब वर्ण नहीं है। शॉर्ट सर्किट मूल्यांकन के कारण ('\ n'! = C) सब-डेप्रिसिएशन का मूल्यांकन नहीं किया जाता है। पाश समाप्त हो जाता है।
फ़ंक्शन ने एक अंतरिक्ष या क्षैतिज टैब वर्ण पढ़ा है। '' \ N '! = C) सबप्रेप्रेशन का मूल्यांकन किया जाता है, लेकिन इसका परिणाम हमेशा सही होता है।

दूसरे शब्दों में, उपरोक्त कोड निम्न के बराबर है:

 for (c = getc (InFile); c==' ' || c == '\t'; c = getc (InFile))

हमने पाया है कि यह वांछित तरीके से काम नहीं करता है। अब देखते हैं कि निहितार्थ क्या हैं।

एक डेवलपर, जिसने ईटव्हीट्सस्पेस फ़ंक्शन के शरीर में आइसस्पेस का कॉल लिखा था, उम्मीद है कि मानक फ़ंक्शन को बुलाया जाएगा। इसलिए उन्होंने एलएफ चरित्र ('\ n') को व्हाट्सएप चरित्र के रूप में व्यवहार करने से रोकने के लिए शर्त को जोड़ा।

इसका मतलब है कि, अंतरिक्ष और क्षैतिज टैब वर्णों के अलावा, वे फॉर्म फ़ीड और ऊर्ध्वाधर टैब वर्णों को भी छोड़ने की योजना बना रहे थे।

क्या अधिक उल्लेखनीय है कि वे चाहते थे कि गाड़ी वापसी चरित्र (0x0d, '\ r') को भी छोड़ दिया जाए। हालांकि ऐसा नहीं होता है - इस चरित्र का सामना करते समय लूप समाप्त हो जाता है। यदि सीआर + एलएफ अनुक्रम द्वारा नईलाइनों का प्रतिनिधित्व किया जाता है, तो यह कार्यक्रम अप्रत्याशित रूप से बर्ताव करने वाला होगा, जो कि कुछ गैर-यूनिक्स प्रणालियों जैसे माइक्रोसॉफ्ट विंडोज में उपयोग किया जाने वाला प्रकार है।

एलएफ या सीआर + एलएफ के उपयोग के नए कारणों के बारे में ऐतिहासिक कारणों के बारे में अधिक जानकारी के लिए, विकिपीडिया पृष्ठ " न्यूलाइन " देखें।

EatWhitespace फ़ंक्शन फ़ाइलों को उसी तरह से संसाधित करने के लिए था, चाहे वे एलएफ या सीआर + एलएफ का उपयोग नए वर्णों के रूप में करें। लेकिन यह CR + LF के मामले में विफल है। दूसरे शब्दों में, यदि आपकी फ़ाइल विंडोज़ की दुनिया से है, तो आप मुश्किल में हैं :)।

हालांकि यह एक गंभीर बग नहीं हो सकता है, विशेष रूप से यह देखते हुए कि GNU मिडनाइट कमांडर का उपयोग UNIX- जैसे ऑपरेटिंग सिस्टम में किया जाता है, जहाँ LF (0x0a, '\ n') को एक नई लाइन वर्ण के रूप में प्रयोग किया जाता है, जैसे कि अभी भी कष्टप्रद हो जाता है। लिनक्स और विंडोज पर तैयार किए गए डेटा की संगतता के साथ समस्याएं।

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

मानक कार्यों को ओवरराइड करना एक बुरा अभ्यास है। वैसे, हमने हाल के लेख " सराहना स्टेटिक कोड एनालिसिस " में #define sprintf std :: printf मैक्रो के एक समान मामले पर चर्चा की।

एक बेहतर समाधान मैक्रो को एक अनूठा नाम देना होगा, उदाहरण के लिए, is_space_or_tab । इससे सभी भ्रम से बचने में मदद मिलती।

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

पढ़ने के लिए धन्यवाद। पीवीएस-स्टूडियो डाउनलोड करने और अपनी परियोजनाओं के साथ प्रयास करने में संकोच न करें। एक अनुस्मारक के रूप में, अब हम जावा का भी समर्थन करते हैं।

एक जासूस खेलना चाहते हैं? आधी रात के कमांडर से एक फंक्शन में बग का पता लगाएं

More articles: