अपरिभाषित व्यवहार और सत्य परिभाषित नहीं है

सी और सी ++ भाषा में "अनिश्चित व्यवहार" शब्द एक ऐसी स्थिति को चित्रित करता है जिसमें शाब्दिक रूप से "केवल क्या नहीं होता है"। ऐतिहासिक रूप से, ऐसे मामलों में जहां पिछले सी कंपाइलर (और उस पर आर्किटेक्चर) ने असंगत व्यवहार किया था, को अनिश्चित व्यवहार के लिए जिम्मेदार ठहराया गया था, और मानक के विकास के लिए समिति ने अपने असीम ज्ञान में, इस बारे में कुछ भी तय नहीं करने का फैसला किया (अर्थात, वरीयता देने के लिए नहीं। प्रतिस्पर्धा के कार्यान्वयन में से कुछ)। अनिश्चित व्यवहार को संभावित परिस्थितियां भी कहा जाता था जिसमें मानक, आमतौर पर इतना थकावट, किसी भी विशिष्ट व्यवहार को निर्धारित नहीं करता था। इस शब्द का एक तीसरा अर्थ है, जो हमारे समय में अधिक से अधिक प्रासंगिक होता जा रहा है: अनिश्चित व्यवहार - यह अनुकूलन का अवसर है। और सी और सी ++ में डेवलपर्स को अनुकूलन पसंद है; वे कोड को गति देने के लिए हर संभव प्रयास करने के लिए कंपाइलरों की आवश्यकता होती है।

यह लेख पहली बार क्रिप्टोग्राफी सर्विसेज वेबसाइट पर प्रकाशित हुआ था। लेखक थॉमस पोर्निन की अनुमति से अनुवाद प्रकाशित हुआ है।

यहाँ एक क्लासिक उदाहरण है:

void foo(double *src, int *dst) { int i; for (i = 0; i < 4; i ++) { dst[i] = (int)src[i]; } } 

हम इस जीसीसी कोड को लिनक्स के तहत 64-बिट x86 प्लेटफॉर्म पर संकलित करेंगे (मैं उबंटू 18.04 के नवीनतम संस्करण पर काम करता हूं, जीसीसी संस्करण 7.3.0 है)। हम पूर्ण अनुकूलन को चालू करते हैं, और फिर कोडांतरक लिस्टिंग को देखते हैं, जिसके लिए हम "-Wall -O9 -S " का उपयोग करते हैं (तर्क " -O9 " जीसीसी ऑप्टिमाइज़ेशन के अधिकतम स्तर को सेट करता है, जो व्यवहार में " -O3 " के बराबर है, हालांकि कुछ कांटे में है। जीसीसी परिभाषित और उच्च स्तर)। हमें निम्न परिणाम मिलते हैं:

  .file "zap.c" .text .p2align 4,,15 .globl foo .type foo, @function foo: .LFB0: .cfi_startproc movupd (%rdi), %xmm0 movupd 16(%rdi), %xmm1 cvttpd2dq %xmm0, %xmm0 cvttpd2dq %xmm1, %xmm1 punpcklqdq %xmm1, %xmm0 movups %xmm0, (%rsi) ret .cfi_endproc .LFE0: .size foo, .-foo .ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0" .section .note.GNU-stack,"",@progbits 

पहले दो मूवमेंट निर्देशों में से प्रत्येक दो डबल मानों को 128-बिट SSE2 रजिस्टर में स्थानांतरित करता है ( डबल का आकार 64 बिट्स है, इसलिए SSE2 रजिस्टर दो दोहरे मूल्यों को संग्रहीत कर सकता है)। दूसरे शब्दों में, चार प्रारंभिक मूल्यों को पहले पढ़ा जाता है, और उसके बाद ही उन्हें इंट ( cvttpd2dq ऑपरेशन) में डाला जाता है। Punpcklqdq ऑपरेशन चार प्राप्त 32-बिट पूर्णांकों को एक SSE2 रजिस्टर (% xmm0 ) में ले जाता है, जिसकी सामग्री को तब RAM ( movups ) में लिखा जाता है। और अब मुख्य बात: हमारे सी-प्रोग्राम को औपचारिक रूप से आवश्यक है कि मेमोरी तक पहुंच निम्नलिखित क्रम में हो:

• Src से पहला दोहरा मूल्य पढ़ें [0] ।
• Dst [0] के प्रकार int का पहला मूल्य लिखें।
• Src [1] से दूसरा दोहरा मूल्य पढ़ें।
• Dst [1] के प्रकार int का दूसरा मूल्य लिखें।
• तीसरा दोहरा मूल्य src [2] से पढ़ें।
• Dst [2] के प्रकार int का तीसरा मान लिखें।
• चौथा डबल मान src [3] से पढ़ें।
• Dst [3] प्रकार के चौथे मान को लिखें।

हालांकि, इन सभी आवश्यकताओं को केवल एक अमूर्त मशीन के संदर्भ में समझ में आता है, जिसे सी मानक परिभाषित करता है; एक वास्तविक मशीन पर प्रक्रिया भिन्न हो सकती है। संकलक संचालन को पुनर्व्यवस्थित या संशोधित करने के लिए स्वतंत्र है, बशर्ते कि उनका परिणाम अमूर्त मशीन (तथाकथित रूप में-अगर नियम "जैसा है") के शब्दार्थ के विपरीत नहीं है। हमारे उदाहरण में, कार्रवाई का क्रम बस अलग है:

• Src से पहला दोहरा मूल्य पढ़ें [0] ।
• Src [1] से दूसरा दोहरा मूल्य पढ़ें।
• तीसरा दोहरा मूल्य src [2] से पढ़ें।
• चौथा डबल मान src [3] से पढ़ें।
• Dst [0] के प्रकार int का पहला मूल्य लिखें।
• Dst [1] के प्रकार int का दूसरा मूल्य लिखें।
• Dst [2] के प्रकार int का तीसरा मान लिखें।
• Dst [3] प्रकार के चौथे मान को लिखें।

यह सी भाषा है: सभी मेमोरी कंटेंट अंततः बाइट्स होते हैं (यानी, टाइप अहस्ताक्षरित चार के मूल्यों के साथ स्लॉट, लेकिन व्यवहार में, आठ बिट्स के समूह), और किसी भी मनमाने ढंग से सूचक संचालन की अनुमति है। विशेष रूप से, src और dst पॉइंटर्स का उपयोग मेमोरी के ओवरलैपिंग भागों तक पहुंचने के लिए किया जा सकता है जब इसे बुलाया जाता है (यह स्थिति "एलियासिंग" कहलाती है)। इस प्रकार, यदि बाइट्स लिखे जाते हैं और फिर दोबारा पढ़े जाते हैं तो रीड एंड राइट ऑर्डर महत्वपूर्ण हो सकता है। सी मानक द्वारा परिभाषित सार के अनुरूप कार्यक्रम के वास्तविक व्यवहार के लिए, संकलक को पढ़ने और लिखने के संचालन के बीच वैकल्पिक करना होगा, प्रत्येक पुनरावृत्ति पर मेमोरी एक्सेस का एक पूरा चक्र प्रदान करना होगा। परिणामी कोड बड़ा होगा और बहुत धीमी गति से काम करेगा। सी डेवलपर्स के लिए, यह एक दुख की बात होगी।

यहाँ, सौभाग्य से, अनिश्चितकालीन व्यवहार बचाव के लिए आता है। मानक C बताता है कि मान उन बिंदुओं के माध्यम से एक्सेस नहीं किए जा सकते हैं, जिनका प्रकार इन प्रकारों के वर्तमान प्रकारों के अनुरूप नहीं है। सीधे शब्दों में, यदि मान dst [0] को लिखा जाता है, जहाँ dst एक int सूचक है, तो संबंधित बाइट्स को src [1] के माध्यम से नहीं पढ़ा जा सकता है, जहाँ src एक दोहरा सूचक है, क्योंकि इस मामले में हम एक्सेस करने का प्रयास करेंगे। मूल्य, जो अब असंगत प्रकार के सूचक का उपयोग करते हुए, टाइप इंट का है। इस मामले में, अपरिभाषित व्यवहार होता है। यह मानक ISO 9899: 1999 ("C99") के अनुभाग 6.5 के पैरा 7 में कहा गया है (नए संस्करण 9899: 2018, या "C17" में, शब्दांकन नहीं बदला है)। इस आवश्यकता को सख्त अलियासिंग नियम कहा जाता है। नतीजतन, सी कंपाइलर को इस धारणा पर कार्य करने की अनुमति है कि मेमोरी एक्सेस संचालन सख्त अलियासिंग नियम के उल्लंघन के कारण अपरिभाषित व्यवहार के लिए अग्रणी है। इस प्रकार, कंपाइलर किसी भी क्रम में पढ़ने और लिखने के संचालन को पुनर्व्यवस्थित कर सकता है, क्योंकि उन्हें मेमोरी के अतिव्यापी भागों तक नहीं पहुंचना चाहिए। यह कोड अनुकूलन क्या है।

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

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

हमारे सशर्त डेवलपर इसे लिखेंगे:

 #include <stdio.h> #include <stdlib.h> int add(int x, int y, int *z) { int r = x + y; if (x > 0 && y > 0 && r < x) { return 0; } if (x < 0 && y < 0 && r > x) { return 0; } *z = r; return 1; } int main(int argc, char *argv[]) { int x, y, z; if (argc != 3) { return EXIT_FAILURE; } x = atoi(argv[1]); y = atoi(argv[2]); if (add(x, y, &z)) { printf("%d\n", z); } else { printf("overflow!\n"); } return 0; } 

अब GCC का उपयोग करके इस कोड को संकलित करने का प्रयास करते हैं:

 $ gcc -W -Wall -O9 testadd.c $ ./a.out 17 42 59 $ ./a.out 2000000000 1500000000 overflow! 

ठीक है, यह काम करने लगता है। अब एक अन्य संकलक का प्रयास करें, उदाहरण के लिए, क्लैंग (मेरे पास संस्करण 6.0.0 है):

 $ clang -W -Wall -O3 testadd.c $ ./a.out 17 42 59 $ ./a.out 2000000000 1500000000 -794967296 

Shta?

यह पता चला है कि जब हस्ताक्षरित पूर्णांक प्रकारों के साथ एक ऑपरेशन का परिणाम होता है जो लक्ष्य प्रकार द्वारा प्रतिनिधित्व नहीं किया जा सकता है, तो हम अपरिभाषित व्यवहार के क्षेत्र में प्रवेश करते हैं। लेकिन कंपाइलर मान सकता है कि ऐसा नहीं होता है। विशेष रूप से, एक्सप्रेशन एक्स> 0 && y> 0 && r <x , का अनुकूलन करते हुए, कंपाइलर निष्कर्ष निकालता है कि चूंकि x और y के मान कड़ाई से सकारात्मक हैं, इसलिए तीसरा चेक सही नहीं हो सकता (दो मानों का योग उनमें से किसी से कम नहीं हो सकता है,) और आप इस पूरे ऑपरेशन को छोड़ सकते हैं। दूसरे शब्दों में, चूंकि अतिप्रवाह एक अपरिभाषित व्यवहार है, इसलिए यह संकलक के दृष्टिकोण से "नहीं हो सकता", और इस राज्य पर निर्भर सभी निर्देशों को हटाया जा सकता है। अपरिभाषित व्यवहार का पता लगाने का तंत्र बस गायब हो गया है।

मानक ने इस धारणा को कभी निर्धारित नहीं किया कि "हस्ताक्षरित शब्दार्थ" (जो कि वास्तव में प्रोसेसर संचालन में उपयोग किया जाता है) का उपयोग हस्ताक्षरित प्रकारों के साथ गणना में किया जाता है; यह परंपरा के बजाय हुआ - उन दिनों में भी जब कोड का अनुकूलन करने के लिए कंपाइलर स्मार्ट नहीं थे, मूल्यों की एक सीमा पर ध्यान केंद्रित करते हुए। आप Clang और GCC को -fwrapv ध्वज (Microsoft Visual C में, आप यहाँ वर्णित के रूप में -d2UndefIntOverflow- का उपयोग कर सकते हैं ) का उपयोग करके हस्ताक्षरित प्रकार के रैपिंग शब्दार्थों को लागू करने के लिए बाध्य कर सकते हैं। हालाँकि, यह दृष्टिकोण अविश्वसनीय है, कोड किसी अन्य प्रोजेक्ट या किसी अन्य आर्किटेक्चर में स्थानांतरित होने पर ध्वज गायब हो सकता है।

कुछ लोगों को पता है कि चरित्र प्रकार के ओवरफ्लो में अपरिभाषित व्यवहार शामिल है। यह मानक C99 और C17 के खंड 6.5 के पैरा 5 में कहा गया है:

यदि एक अभिव्यक्ति का मूल्यांकन करते समय एक अपवाद होता है (अर्थात, यदि परिणाम गणितीय रूप से परिभाषित नहीं है या किसी दिए गए प्रकार के वैध मूल्यों की सीमा के बाहर है), तो व्यवहार अपरिभाषित है।

अहस्ताक्षरित प्रकारों के लिए, हालाँकि, मॉड्यूलर शब्दार्थ की गारंटी दी जाती है। खंड 6.2.5 के अनुच्छेद 9 में निम्नलिखित कहा गया है:

अहस्ताक्षरित ऑपरेंड के साथ गणना में ओवरफ्लो कभी नहीं होता है, जिसके परिणामस्वरूप परिणामस्वरूप अहस्ताक्षरित पूर्णांक प्रकार का प्रतिनिधित्व नहीं किया जा सकता है, एक संख्या को छोटा किया जाता है जो कि परिणामस्वरूप प्रकार द्वारा दर्शाए गए अधिकतम मूल्य से एक अधिक होता है।

हस्ताक्षरित प्रकारों के साथ संचालन में अपरिभाषित व्यवहार का एक और उदाहरण विभाजन ऑपरेशन है। जैसा कि सभी जानते हैं, शून्य से विभाजन का परिणाम गणितीय रूप से निर्धारित नहीं होता है, इसलिए, मानक के अनुसार, यह ऑपरेशन अपरिभाषित व्यवहार को मजबूर करता है। यदि x86 प्रोसेसर पर इडिव ऑपरेशन में डिवाइडर शून्य है, तो प्रोसेसर अपवाद को फेंक दिया जाता है। व्यवधान अनुरोधों की तरह, प्रोसेसर अपवादों को ऑपरेटिंग सिस्टम द्वारा नियंत्रित किया जाता है। यूनिक्स जैसी प्रणालियों पर, जैसे कि लिनक्स, idiv ऑपरेशन द्वारा ट्रिगर किए गए प्रोसेसर अपवाद को एक SIGFPE सिग्नल में अनुवादित किया जाता है, जो प्रक्रिया को भेजा जाता है, और यह डिफ़ॉल्ट हैंडलर के साथ समाप्त होता है (आश्चर्यचकित न हों कि "FPE" "फ़्लोटिंग-पॉइंट अपवाद" अपवाद है) फ्लोटिंग पॉइंट ऑपरेशंस), जबकि आइडिव पूर्णांक के साथ काम करता है)। लेकिन एक और स्थिति है जो अपरिभाषित व्यवहार की ओर ले जाती है। निम्नलिखित कोड पर विचार करें:

 #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { int x, y; if (argc != 3) { return EXIT_FAILURE; } x = atoi(argv[1]); y = atoi(argv[2]); printf("%d\n", x / y); return 0; }  : $ gcc -W -Wall -O testdiv.c $ ./a.out 42 17 2 $ ./a.out -2147483648 -1 zsh: floating point exception (core dumped) ./a.out -2147483648 -1 

और सच्चाई यह है: इस मशीन (लिनक्स के लिए समान x86) पर, इंट प्रकार -2,147,483,648 से +2,147,483,647 तक मानों की एक श्रृंखला का प्रतिनिधित्व करता है। यदि आप -2,147,483,648 को -1 से विभाजित करते हैं, तो आपको +2,147,483,648 प्राप्त करना चाहिए। लेकिन यह संख्या अंतर मूल्यों की सीमा में नहीं है। इसलिए, व्यवहार परिभाषित नहीं है। कुछ भी हो सकता है। इस मामले में, प्रक्रिया को जबरन समाप्त कर दिया जाता है। एक और प्रणाली पर, विशेष रूप से एक छोटे प्रोसेसर के साथ जिसमें विभाजन ऑपरेशन नहीं होता है, परिणाम भिन्न हो सकता है। ऐसे आर्किटेक्चर में, डिवीजन को प्रोग्रामेटिक रूप से निष्पादित किया जाता है - आमतौर पर कंपाइलर द्वारा प्रदान की गई प्रक्रिया का उपयोग करते हुए, और अब यह अनिश्चित व्यवहार के साथ जो कुछ भी करता है, वह कर सकता है, क्योंकि यही वह है।

मैं ध्यान देता हूं कि SIGFPE को उन्हीं परिस्थितियों में और modulo ऑपरेटर ( % ) की मदद से प्राप्त किया जा सकता है। और वास्तव में: इसके तहत एक ही आइडिएव ऑपरेशन निहित है, जो भागफल और शेष दोनों की गणना करता है, इसलिए एक ही प्रोसेसर अपवाद को ट्रिगर किया जाता है। दिलचस्प है, C99 मानक का कहना है कि अभिव्यक्ति INT_MIN% -1 अपरिभाषित व्यवहार नहीं कर सकता है, क्योंकि परिणाम गणितीय रूप से परिभाषित (शून्य) है और स्पष्ट रूप से लक्ष्य प्रकार के मूल्यों की सीमा में प्रवेश करता है। संस्करण C17 में, खंड 6.5.5 के पैराग्राफ 6 के पाठ को बदल दिया गया है, और अब इस मामले को भी ध्यान में रखा गया है, जो सामान्य हार्डवेयर प्लेटफार्मों पर मानक को वास्तविक स्थिति के करीब लाता है।

कई स्पष्ट स्थितियां हैं जो अपरिभाषित व्यवहार का कारण बनती हैं। इस कोड पर एक नज़र डालें:

 #include <stdio.h> #include <stdlib.h> unsigned short mul(unsigned short x, unsigned short y) { return x * y; } int main(int argc, char *argv[]) { int x, y; if (argc != 3) { return EXIT_FAILURE; } x = atoi(argv[1]); y = atoi(argv[2]); printf("%d\n", mul(x, y)); return 0; } 

क्या आपको लगता है कि C मानक का पालन करते हुए एक प्रोग्राम प्रिंट करना चाहिए, अगर हम फ़ंक्शन को 45,000 और 50,000 पास करते हैं?

• 18,048
• 2250000000
• भगवान बचाओ रानी!

सही उत्तर ... हाँ, उपरोक्त सभी! आप शायद इस तरह से तर्क देते हैं: चूंकि अहस्ताक्षरित शॉर्ट एक अहस्ताक्षरित प्रकार है, इसलिए इसे रैपिंग मोडुलो 65 536 के शब्दार्थ का समर्थन करना चाहिए, क्योंकि x86 प्रोसेसर पर इस प्रकार का आकार, एक नियम के रूप में, बिल्कुल 16 बिट्स है (मानक भी बड़े आकार की अनुमति देता है, लेकिन व्यवहार में, यह अभी भी एक 16-बिट प्रकार है)। चूंकि गणितीय रूप से उत्पाद 2,250,000,000 है, इसलिए इसे 65,536 मोड्यूल किया जाएगा, जो 18,048 का उत्तर देता है। हालांकि, इस तरह से सोचते हुए, हम पूर्णांक प्रकारों के विस्तार के बारे में भूल जाते हैं। सी मानक (धारा 6.3.1.1, पैराग्राफ 2) के अनुसार, यदि ऑपरेंड एक प्रकार के होते हैं, जिनका आकार इंट के आकार की तुलना में कड़ाई से छोटा होता है, और इस प्रकार के मूल्यों को बिट्स के नुकसान के बिना इंट प्रकार द्वारा दर्शाया जा सकता है (और हमारे पास केवल यह मामला है: मेरे x86 के तहत लिनक्स में 32 बिट्स का एक अंतर आकार है, और यह 0 से 65,535 तक स्पष्ट रूप से मूल्यों को संग्रहीत कर सकता है), फिर दोनों ऑपरेंड को इंट में डाला जाता है और पहले से ही परिवर्तित मूल्यों पर ऑपरेशन किया जाता है। अर्थात्: उत्पाद को प्रकार के मान के रूप में परिकलित किया जाता है , और केवल फ़ंक्शन से लौटने के बाद इसे बिना छोड़े शॉर्ट में लाया जाता है (अर्थात, यह इस समय है कि ट्रंकेशन मोडुलो 65 536 होता है)। समस्या यह है कि गणितीय रूप से उलटा परिवर्तन से पहले परिणाम 2.250 मिलियन है, और यह मान इंट की सीमा से अधिक है, जो एक हस्ताक्षरित प्रकार है। नतीजतन, हमें अपरिभाषित व्यवहार मिलता है। उसके बाद, अंग्रेजी देशभक्ति के अचानक मुकाबलों सहित कुछ भी हो सकता है।

हालांकि, सामान्य संकलक के साथ व्यवहार में, परिणाम 18,048 है, क्योंकि अभी भी कोई अनुकूलन नहीं है जो इस विशेष कार्यक्रम में अनिश्चित व्यवहार का लाभ उठा सकता है (एक और अधिक कृत्रिम परिदृश्यों की कल्पना कर सकता है जहां यह वास्तव में परेशानी पैदा करेगा)।

अंत में, C ++ में अब एक और उदाहरण:

 #include <stdio.h> #include <stdlib.h> #include <string.h> #include <array> int main(int argc, char *argv[]) { std::array<char, 16> tmp; int i; if (argc < 2) { return EXIT_FAILURE; } memset(tmp.data(), 0, 16); if (strlen(argv[1]) < 16) { strcpy(tmp.data(), argv[1]); } for (i = 0; i < 17; i ++) { printf(" %02x", tmp[i]); } printf("\n"); } 

यह आप के लिए विशिष्ट "बुरा भयानक strcpy () नहीं है !" वास्तव में, यहाँ strcpy () फ़ंक्शन को केवल तभी निष्पादित किया जाता है, जब टर्मिनल शून्य सहित स्रोत स्ट्रिंग का आकार काफी छोटा हो। इसके अलावा, सरणी के तत्वों को स्पष्ट रूप से शून्य पर आरंभीकृत किया जाता है, इसलिए सरणी में सभी बाइट्स को एक दिया गया मान है, भले ही एक बड़े या छोटे स्ट्रिंग को फ़ंक्शन में पारित किया गया हो। इसी समय, अंत में लूप गलत है: यह एक बाइट को जितना चाहिए उससे अधिक पढ़ता है।

कोड चलाएँ:

 $ g++ -W -Wall -O9 testvec.c $ ./a.out foo 66 6f 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 10 58 ffffffca ff ffffac ffffffc0 55 00 00 00 ffffff80 71 34 ffffff99 07 ffffffba ff ffffea ffffffd0 ffffffe5 44 ffffff83 fffffffd 7f 00 00 00 00 00 00 00 00 00 00 10 58 ffffffca ffffffac ffffffc0 55 00 00 ffffff97 7b 12 1b ffffffa1 7f 00 00 02 00 00 00 00 00 00 00 ffffffd8 ffffffe5 44 ffffff83 fffffffd 7f 00 00 00 ffffff80 00 00 02 00 00 00 60 56 (...) 62 64 3d 30 30 zsh: segmentation fault (core dumped) ./a.out foo ++? 

आप स्वाभाविक रूप से ऑब्जेक्ट कर सकते हैं: अच्छी तरह से, यह सरणी की सीमा से परे एक अतिरिक्त बाइट पढ़ता है; लेकिन यह इतना डरावना नहीं है, क्योंकि स्टैक पर यह बाइट अभी भी है, यह स्मृति में मैप किया जाता है, इसलिए यहां एकमात्र समस्या एक अज्ञात मूल्य के साथ अतिरिक्त सत्रहवें तत्व है। चक्र अभी भी 17 पूर्णांक (हेक्साडेसिमल प्रारूप में) को प्रिंट करेगा और बिना किसी शिकायत के समाप्त होगा।

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

यह हास्यास्पद है, लेकिन अगर जीसीसी अनुकूलन के लिए कम आक्रामक सेटिंग्स के साथ शुरू होता है, तो यह चेतावनी देगा:

 $ g++ -W -Wall -O1 testvec.c testvec.c: In function 'int main(int, char**)': testvec.c:20:15: warning: iteration 16 invokes undefined behavior [-Waggressive-loop-optimizations] printf(" %02x", tmp[i]); ~~~~~~^~~~~~~~~~~~~~~~~ testvec.c:19:19: note: within this loop for (i = 0; i < 17; i ++) { ~~^~~~ 

-ओ 9 पर, यह चेतावनी किसी तरह गायब हो जाती है। शायद तथ्य यह है कि अनुकूलन के उच्च स्तर पर, संकलक अधिक आक्रामक रूप से लूप की तैनाती को लागू करता है। यह संभव है (लेकिन गलत है) यह एक जीसीसी बग है (चेतावनी के नुकसान के अर्थ में; इस प्रकार, किसी भी मामले में जीसीसी की कार्रवाई मानक के विपरीत नहीं है, क्योंकि इस स्थिति में इसे "निदान" जारी करने की आवश्यकता नहीं है)।

निष्कर्ष: यदि आप C या C ++ में कोड लिख रहे हैं, तो अत्यधिक सावधान रहें और ऐसी स्थितियों से बचें जो अपरिभाषित व्यवहार की ओर ले जाती हैं, भले ही ऐसा लगता है कि यह "ठीक है"।

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