क्या ऐसा कोड जिसे कभी भी अपरिभाषित व्यवहार के लिए लागू नहीं किया जाएगा?

Question

कोड जो अपरिभाषित व्यवहार को आमंत्रित करता है (इस उदाहरण में, शून्य से विभाजन) कभी भी निष्पादित नहीं होगा, क्या कार्यक्रम अभी भी अपरिभाषित व्यवहार है?

int main(void)
{
    int i;
    if(0)
    {
        i = 1/0;
    }
    return 0;
}

मुझे लगता है कि यह अभी भी अपरिभाषित व्यवहार है, लेकिन मुझे समर्थन देने या मुझे अस्वीकार करने के मानक में कोई प्रमाण नहीं मिला है।

तो, कोई विचार?

Comments

मैं कहूंगा कि यह "व्यवहार" नहीं है यदि इसे कभी भी निष्पादित नहीं किया गया है

— केविन

यदि यूबी रनटाइम एक (इस तरह) है - यह नहीं होगा। लेकिन मैं अत्यधिक संदेह मानक इस बारे में कुछ भी कहता हूं।

— केल्टर 22'13

प्रोग्रामिंग नहीं, शब्दार्थ के प्रश्न की तरह लगता है।

— Wooble

@ मैं असहमत हूं। वाक्यांश अपरिभाषित व्यवहार का C / C ++ में एक विशेष अर्थ है। और यह सवाल कुछ अन्य स्थितियों से संबंधित है जो अपरिभाषित व्यवहार को निर्धारित करता है या नहीं। रिकॉर्ड के लिए, यदि आपने C / C ++ मानक पढ़ा है, तो आपको हर जगह वाक्यांश अपरिभाषित व्यवहार मिलेगा ।

— यू हाओ

@Cornstalks: C मानक "अपरिभाषित व्यवहार को आमंत्रित करता है" वाक्यांश का उपयोग नहीं करता है, इसलिए आप C मानक के बारे में तर्क नहीं दे सकते कि यह वाक्यांश क्या अर्थ हो सकता है। सी का वर्णन करने के लिए इसका उपयोग करना अनुचित है क्योंकि यह सुझाव देता है कि "अपरिभाषित व्यवहार" एक ऐसी चीज है जैसे कि आप जिस दीवार पर चलते हैं यदि आप सीमा से बाहर जाते हैं। वास्तव में, "अपरिभाषित व्यवहार" एक चीज़ की कमी है; यह सीमाओं का अंत है। जब आप अच्छी तरह से परिभाषित शहर छोड़ देते हैं जो मानक सी है, तो आप एक खुले क्षेत्र में हैं जहां कुछ भी बनाया जा सकता है।

— एरिक पोस्टपिसिल

Answer 1

आइए देखें कि सी मानक "व्यवहार" और "अपरिभाषित व्यवहार" शब्दों को कैसे परिभाषित करता है।

संदर्भ आईएसओ सी 2011 मानक के एन 1570 ड्राफ्ट के हैं; मैं प्रकाशित तीन सी आईएसओ मानकों (1990, 1999 और 2011) में से किसी में भी प्रासंगिक अंतरों से अवगत नहीं हूं।

धारा 3.4:

व्यवहार
बाहरी रूप या क्रिया

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

धारा 3.4.3:

अपरिभाषित
या गलत प्रोग्राम निर्माण, या गलत डेटा के उपयोग पर अपरिभाषित व्यवहार व्यवहार, जिसके लिए यह अंतर्राष्ट्रीय मानक कोई आवश्यकता नहीं लगाता है

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

उस परिभाषा के तहत एक नोट है:

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

तो एक कंपाइलर को आपके प्रोग्राम को संकलन समय पर अस्वीकार करने की अनुमति दी जाती है यदि उसका व्यवहार अपरिभाषित है। लेकिन मेरी व्याख्या यह है कि यह केवल तभी कर सकता है जब यह साबित कर सकता है कि कार्यक्रम का हर निष्पादन अपरिभाषित व्यवहार का सामना करेगा। जिसका अर्थ है, मुझे लगता है कि यह:

if (rand() % 2 == 0) {
    i = i / 0;
}

जो निश्चित रूप से कर सकते हैं अपरिभाषित व्यवहार है, संकलन समय पर अस्वीकार नहीं किया जा सकता है।

एक व्यावहारिक मामले के रूप में, अपरिभाषित व्यवहार को रोकने के लिए कार्यक्रमों को रनटाइम परीक्षण करने में सक्षम होना चाहिए, और मानक को उन्हें ऐसा करने की अनुमति देनी होगी।

आपका उदाहरण था:

if (0) {
    i = 1/0;
}

जो कभी भी डिवीजन को 0. निष्पादित नहीं करता है: एक बहुत ही सामान्य मुहावरा है:

int x, y;
/* set values for x and y */
if (y != 0) {
    x = x / y;
}

विभाजन निश्चित रूप से अपरिभाषित व्यवहार है अगर y == 0, लेकिन यह कभी भी निष्पादित नहीं होता है y == 0। व्यवहार अच्छी तरह से परिभाषित है, और उसी कारण से कि आपका उदाहरण अच्छी तरह से परिभाषित है: क्योंकि क्षमता अपरिभाषित व्यवहार वास्तव में कभी नहीं हो सकता है।

(जब तक INT_MIN < -INT_MAX && x == INT_MIN && y == -1(हाँ, पूर्णांक विभाजन ओवरफ्लो हो सकता है), लेकिन यह एक अलग मुद्दा है।)

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

i = 1/0;

1/0 एक स्थिर अभिव्यक्ति नहीं है ।

एक स्थिर-अभिव्यक्ति एक वाक्यात्मक श्रेणी है जो सशर्त-अभिव्यक्ति (जो असाइनमेंट और अल्पविराम अभिव्यक्तियों को छोड़कर ) को कम करती है । उत्पादन निरंतर-अभिव्यक्ति व्याकरण में केवल संदर्भों में प्रकट होती है, जिन्हें वास्तव में एक स्थिर अभिव्यक्ति की आवश्यकता होती है, जैसे कि केस लेबल। इसलिए यदि आप लिखते हैं:

switch (...) {
    case 1/0:
    ...
}

तब 1/0एक स्थिर अभिव्यक्ति है - और 6.6p4 में एक बाधा का उल्लंघन करता है: "प्रत्येक स्थिर अभिव्यक्ति एक ऐसे निरंतर का मूल्यांकन करेगी जो उसके प्रकार के लिए प्रतिनिधित्व योग्य मूल्यों की सीमा में है।", इसलिए एक निदान की आवश्यकता है। लेकिन एक असाइनमेंट के दाहिने हाथ की ओर एक स्थिर-अभिव्यक्ति की आवश्यकता नहीं है , केवल एक सशर्त-अभिव्यक्ति है , इसलिए निरंतर अभिव्यक्तियों पर बाधाएं लागू नहीं होती हैं। एक संकलक किसी भी अभिव्यक्ति का मूल्यांकन कर सकता है जो कि संकलन के समय में सक्षम है, लेकिन केवल तभी व्यवहार समान है जब इसे निष्पादन के दौरान मूल्यांकन किया गया था (या, संदर्भ में if (0), निष्पादन के दौरान मूल्यांकन नहीं किया गया है)।

(कुछ ऐसा जो वास्तव में एक जैसी लगती है निरंतर अभिव्यक्ति जरूरी नहीं कि एक है निरंतर अभिव्यक्ति , बस के रूप में, में x + y * z, अनुक्रम x + yएक नहीं है additive अभिव्यक्ति संदर्भ में यह प्रतीत होता है की वजह से।)

जिसका अर्थ है N1570 खंड 6.6 में फुटनोट जो मैं उद्धृत करने जा रहा था:

इस प्रकार, निम्नलिखित आरंभीकरण में,
static int i = 2 || 1 / 0;
भाव एक मान के साथ एक मान्य पूर्णांक स्थिर अभिव्यक्ति है।

वास्तव में इस प्रश्न के लिए प्रासंगिक नहीं है।

अंत में, कुछ चीजें हैं जिन्हें अपरिभाषित व्यवहार के कारण परिभाषित किया जाता है जो कि निष्पादन के दौरान क्या होता है। अनुलग्नक जे, सी मानक के खंड 2 (फिर से, एन 1570 ड्राफ्ट देखें ) उन चीजों को सूचीबद्ध करता है जो अपरिभाषित व्यवहार का कारण बनता है, बाकी मानक से इकट्ठा किया जाता है। कुछ उदाहरण (मेरा दावा है कि यह एक विस्तृत सूची नहीं है) हैं:

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

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

Comments

@EricPostpischil 6.6 / 4 कहता है "प्रत्येक स्थिर अभिव्यक्ति एक ऐसे निरंतर का मूल्यांकन करेगी जो उसके प्रकार के लिए प्रतिनिधित्व योग्य मूल्यों की सीमा में है।" 1/0एक स्थिर अभिव्यक्ति होने से बाहर नहीं होगा ?

— केसी

@ EricPostpischil: मुझे नहीं लगता कि यह काफी सही है। एक बाधा का उल्लंघन आम तौर पर मतलब है कि नैदानिक एक संकलन समय की आवश्यकता है, न केवल कि कुछ है कि अन्यथा एक हो सकता है foo एक नहीं है foo । प्रश्न के संदर्भ में1/0 एक स्थिर अभिव्यक्ति नहीं है क्योंकि इसे एक स्थिर-अभिव्यक्ति के रूप में नहीं रखा गया है , केवल एक सशर्त-अभिव्यक्ति के रूप में जो एक असाइनमेंट-अभिव्यक्ति का हिस्सा है । बाधा का उल्लंघन होगा और निदान की आवश्यकता होगी। case 1/0:

— कीथ थॉम्पसन

DR # 109 इंगित करता है कि कार्यक्रम यूबी नहीं है, नया उत्तर देखें जिसे मैंने अभी पोस्ट किया है।

— ahउह

" तो हम आम अंग्रेजी अर्थ में वापस आते हैं ", अंग्रेजी अर्थ में, प्रोग्राम एक निर्माण का उपयोग करता है यदि यह कार्यक्रम में मौजूद है। तो क्यों एक निर्माण का उपयोग कर अपने जवाब एक निर्माण का मतलब है मान? आपकी व्याख्या से आपके निष्कर्ष का पालन नहीं होता है!

— इकेगामी

Answer 2

यह लेख इस प्रश्न पर खंड २.६ में चर्चा करता है:

int main(void){
      guard();
      5 / 0;
}

लेखक मानते हैं कि कार्यक्रम तब परिभाषित होता guard()है जब समाप्त नहीं होता है। वे खुद को "सांख्यिकीय रूप से अपरिभाषित" और "गतिशील रूप से अपरिभाषित" की धारणाओं में भिन्न पाते हैं, उदाहरण के लिए:

मानक ^{11 के} पीछे का अभिप्राय यह है कि सामान्य रूप से, स्थितियों को वैधानिक रूप से अपरिभाषित किया जाता है यदि उनके लिए कोड उत्पन्न करना आसान नहीं है। केवल जब कोड उत्पन्न किया जा सकता है, तो स्थिति को गतिशील रूप से अपरिभाषित किया जा सकता है।

11) समिति के सदस्य के साथ निजी पत्राचार।

मैं पूरे लेख को देखने की सलाह दूंगा। एक साथ लिया, यह एक सुसंगत चित्र पेंट करता है।

तथ्य यह है कि लेख के लेखकों को एक समिति के सदस्य के साथ सवाल पर चर्चा करनी थी, इस बात की पुष्टि करता है कि मानक वर्तमान में आपके प्रश्न के उत्तर पर फजी है।

Comments

यह उदाहरण केवल कठिनाइयों को प्रस्तुत करता है कि क्या आप यह निर्धारित कर सकते हैं कि क्या इसका व्यवहार अपरिभाषित है। जब यह चलता है (यह मानते हुए कि व्यवहार guard()अपरिभाषित नहीं है), तो व्यवहार अपरिभाषित होता है यदि और केवल तभी जब कथन 5 / 0;को निष्पादित किया जाता है। (ध्यान दें कि एक कंपाइलर वैध रूप से 5 / 0कॉल के साथ abort()या कुछ इसी तरह के मूल्यांकन को प्रतिस्थापित कर सकता है ; प्रोग्राम तब ही गर्भपात करेगा अगर और केवल अगर निष्पादन उस बिंदु तक पहुंचता है।) एक कंपाइलर केवल उस प्रोग्राम को अस्वीकार कर सकता है यदि वह यह निर्धारित कर सकता है कि guard()हमेशा समाप्त हो जाएगा।

— कीथ थॉम्पसन

@KeithThompson लेख में स्थिर / गतिशील अंतर को स्पष्ट करने के लिए, 5/0 को गतिशील माना जाता है क्योंकि संकलक कोड उत्पन्न कर सकता है जो शून्य से विभाजित होता है: बस z को 0. पर सेट करने के बाद z द्वारा विभाजित होने वाला सामान्य कोड उत्पन्न करता है। इस प्रकार एक भोली कंपाइलर एक विभाजन निर्देश उत्पन्न कर सकता है। एक परिष्कृत कंपाइलर जो यह निर्धारित guard()करता है कि समाप्त नहीं होता है उसे 5/0 के लिए कोई कोड उत्पन्न नहीं करना है। इसके विपरीत, कोड को जेनरेट करने का कोई तरीका नहीं है, कोई (int)(void)5केवल कोड को उत्पन्न नहीं कर सकता है (int)(void)z, क्योंकि यह सही भी नहीं है। इसलिए लेखक सोचते हैं कि ...

— पास्कल क्यूक

@KeithThompson… एक कंपाइलर को प्रोग्राम को अस्वीकार करने की अनुमति है if (0) (int)(void)5;क्योंकि यह जन्मजात कंपाइलर को प्रस्तुत करता है, जबकि अगम्य गतिशील यूबी जैसे कि if (0) 5 / 0;हानिरहित है। यह वही है जो एक समिति के सदस्य के साथ उनकी चर्चा से स्थानांतरित हो गया है और मैंने एक समान तर्क कहीं और देखा है (लेकिन शायद एक ही स्रोत से, खासकर जब से मुझे याद नहीं है कि यह कहाँ था)। मैं इस समय C99 तर्क के माध्यम से जा रहा हूं, अगर मुझे इसका कोई उल्लेख दिखाई दे तो मैं वापस आकर इसे इंगित करूंगा।

— पास्कल क्यूक

(int)(void)5एक बाधा उल्लंघन है। N1570 6.5.4, कास्ट ऑपरेटर का वर्णन: "अड़चन: जब तक प्रकार नाम एक शून्य प्रकार निर्दिष्ट नहीं करता है, तब तक टाइप नाम परमाणु, योग्य या अयोग्य स्केलर प्रकार निर्दिष्ट करेगा, और ऑपरेंड में स्केलर प्रकार होगा।" (void)5अदिश प्रकार नहीं होता है, इसलिए (int)(void)5उस बाधा का उल्लंघन होता है, चाहे कोड वाले को कभी भी निष्पादित किया जाए।

— कीथ थॉम्पसन

@KeithThompson हां, वे गलत उदाहरण उठाते दिखते हैं, लेकिन J.2 में लंबी सूची के अंदर, एक ऐसा है जो एक बाधा नहीं है और वह है "स्थिर", निश्चित रूप से? उस पुराने क्लासिक के बारे में कैसे, "एक गैर-रिक्त स्रोत फ़ाइल एक नई-पंक्ति वर्ण में समाप्त नहीं होती है ..."? इस पर लागू होने वाली पुनरावृत्ति की कोई धारणा नहीं है, लेकिन यह एक बाधा का उल्लंघन नहीं है, क्या यह है?

— पास्कल कूउक

Answer 3

इस मामले में अपरिभाषित व्यवहार कोड को निष्पादित करने का परिणाम है। इसलिए यदि कोड निष्पादित नहीं किया गया है, तो कोई अपरिभाषित व्यवहार नहीं है।

गैर निष्पादित कोड अपरिभाषित व्यवहार को आमंत्रित कर सकता है यदि अपरिभाषित व्यवहार पूरी तरह से कोड की घोषणा का परिणाम था (उदाहरण के लिए अगर चर छायांकन का कुछ मामला अपरिभाषित था)।

Comments

केस # 2 के उदाहरण के लिए, विचार करें #include "//e"कि कौन सा यूबी को आमंत्रित करता है।

— माइकल फोकरिसिस

Answer 4

मैं इस उत्तर के अंतिम पैराग्राफ के साथ जाऊंगा: https://stackoverflow.com/a/18384176/694576

... यूबी एक रनटाइम इश्यू है, कंप्लेंटटाइम इश्यू नहीं ...

तो, नहीं, कोई यूबी आमंत्रित नहीं है।

Comments

आपको इंटरनेट पर पढ़ी गई हर चीज पर विश्वास नहीं करना चाहिए, खासकर उस स्टैकऑवरफ्लो उत्तर से नहीं।

— पास्कल क्यूक

@PascalCuoq यह मेरे जैसे कई विश्वासियों के विश्वास को चकनाचूर कर देता है। अब कहाँ जाना है?

— डेसीमल 0

Answer 5

केवल जब मानक ब्रेकिंग परिवर्तन करता है और आपका कोड अचानक "कभी निष्पादित नहीं होता है" होता है। लेकिन मुझे ऐसा कोई तार्किक तरीका नहीं दिख रहा है जिसमें यह 'अपरिभाषित व्यवहार' का कारण बन सके। इसके कारण कुछ भी नहीं ।

Answer 6

अपरिभाषित व्यवहार के विषय पर व्यावहारिक लोगों से औपचारिक पहलुओं को अलग करना अक्सर कठिन होता है। यह 1989 के मानक में अपरिभाषित व्यवहार की परिभाषा है (मेरे पास हाल ही में अधिक संस्करण नहीं है, लेकिन मुझे उम्मीद नहीं है कि यह काफी बदल गया है):

1 अपरिभाषित व्यवहार
  व्यवहार, किसी गैर-योग्य या गलत प्रोग्राम के निर्माण या उपयोग पर
  गलत डेटा, जिसके लिए यह अंतर्राष्ट्रीय मानक कोई आवश्यकता नहीं रखता है
2 नोट संभव अपरिभाषित व्यवहार पूरी तरह से स्थिति की अनदेखी से लेकर है
  अप्रत्याशित परिणामों के साथ, अनुवाद या कार्यक्रम के निष्पादन के दौरान व्यवहार करना
  पर्यावरण के साथ (या उसके बिना) की एक प्रलेखित तरीके से विशेषता
  एक नैदानिक ​​संदेश जारी करना), अनुवाद को समाप्त करने के लिए या
  निष्पादन (एक नैदानिक ​​संदेश जारी करने के साथ)।

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

दूसरी ओर, व्यावहारिक दृष्टिकोण से, मुझे एक कंपाइलर को देखकर आश्चर्य होगा जो आपके द्वारा सहज रूप से अपेक्षा के अनुरूप व्यवहार नहीं किया गया था।

Answer 7

मानक कहते हैं, जैसा कि मुझे सही याद है, यह पल से कुछ भी करने की अनुमति है, एक नियम टूट गया। हो सकता है कि इस तरह के वैश्विक स्वाद के साथ कुछ विशेष कार्यक्रम हों (लेकिन मैंने कभी ऐसा कुछ नहीं सुना या पढ़ा हो) ... तो मैं कहूंगा: नहीं, यह यूबी नहीं हो सकता है, क्योंकि जब तक व्यवहार अच्छी तरह से परिभाषित किया जाता है, तब तक मार्ग है गलत है, इसलिए नियम रनटाइम पर नहीं टूट सकता।

Comments

0 हमेशा सच होता है? या यहां तक ​​कि सच है? क्या आप किसी प्रकार के माणिकवादी हैं ?!

— ग्रैडी प्लेयर

@Grady PlayerNo मैं किसी तरह का ब्रेन एफके jsut था। मैं इसे ठीक करने जा रहा हूँ, क्षमा करें

— dhein

Answer 8

मुझे लगता है कि यह अभी भी अपरिभाषित व्यवहार है, लेकिन मुझे समर्थन देने या मुझे अस्वीकार करने के मानक में कोई प्रमाण नहीं मिला है।

मुझे लगता है कि कार्यक्रम अपरिभाषित व्यवहार को आमंत्रित नहीं करता है।

दोष रिपोर्ट # 109 एक समान प्रश्न को संबोधित करता है और कहता है:

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

Answer 9

यह इस बात पर निर्भर करता है कि अभिव्यक्ति "अपरिभाषित व्यवहार" को कैसे परिभाषित किया जाता है, और एक बयान के "अपरिभाषित व्यवहार" एक कार्यक्रम के लिए "अपरिभाषित व्यवहार" के रूप में ही है।

यह कार्यक्रम सी की तरह दिखता है, इसलिए कंपाइलर द्वारा उपयोग किए गए सी मानक (जैसा कि कुछ उत्तरों ने किया) का गहन विश्लेषण उचित है।

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

अन्य भाषाओं में "बंधी त्रुटियों" की अवधारणा है। कुछ सीमित प्रकार की त्रुटियों के लिए, ये भाषाएँ परिभाषित करती हैं कि एक त्रुटि कितना नुकसान पहुँचा सकती है। निहित कचरा संग्रह के साथ विशेष भाषाओं में अक्सर एक फर्क पड़ता है कि क्या त्रुटि टाइपिंग सिस्टम को अमान्य करती है या नहीं।