अंडरवर्ल्ड से थोड़ा सी-समारोह

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

मैंने इस तरह एक समारोह लिखा:

int foo (char x) { char y = x; return ++x > y; } 

चूंकि ++x 1 से बढ़ाता है, इसलिए यह स्पष्ट है कि फ़ंक्शन को अधिकांश x मानों के लिए " 1 " वापस करना चाहिए। सवाल यह है कि यह मूल्य CHAR_MAX के लिए क्या लौटाएगा?

एक धारणा यह थी कि फ़ंक्शन निश्चित रूप से " 0 " लौटाएगा। एक और यह है कि ++x प्लेटफार्मों पर परिभाषित नहीं है जहां चार्ट एक हस्ताक्षरित प्रकार है। अंत में, एक परीक्षण कार्यक्रम लिखा गया था जो सभी संभावित विकल्पों के लिए निष्कर्ष मुद्रित करता है x :

 int main (void) { int i; for (i=CHAR_MIN; i<=CHAR_MAX; i++) { printf ("%d ", foo(i)); if ((i&31)==31) printf ("\n"); } return 0; } 

यह कोड केवल उन प्लेटफ़ॉर्म पर काम करता है, जहाँ char इंट से कम है, लेकिन मैंने ऐसे प्लेटफ़ॉर्म नहीं देखे हैं, जहाँ विपरीत हुआ हो।
जब मैंने क्लैंग का उपयोग करके कोड संकलित किया तो पहली अलार्म घंटी बजी:

 regehr@home:~$ clang -O foo.c -o foo regehr@home:~$ ./foo 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

एक बर्फ बिल्कुल नहीं - एक फ़ंक्शन को ज्यादातर मामलों में एक इकाई वापस करना चाहिए। तब मुझे एहसास हुआ कि मैं क्लैंग (2.7) के एक पुराने संस्करण का उपयोग कर रहा था और नवीनतम स्नैपशॉट डाउनलोड किया (126534 पर क्लिक करें) ( अनुच्छेद 3 मार्च 2011 को लिखा गया था - लगभग प्रति। ):

 regehr@home:~$ clang -O0 overflow.c -o overflow regehr@home:~$ ./overflow 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 regehr@home:~$ clang -O1 overflow.c -o overflow regehr@home:~$ ./overflow 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

अंतिम संकेत पर ध्यान दें। जब हमने ऑप्टिमाइज़ेशन स्तर को बदला तो परिणाम बदल गया - बढ़े हुए CHAR_MAX के मूल्य को परिभाषित नहीं किया गया तो यह सामान्य है, अन्यथा यह एक संकलक त्रुटि है।

इंटेल सी कंपाइलर (x86-64 के लिए 12.0.2) एक समान तरीके से व्यवहार किया गया:

 [regehr@bethe ~]$ icc -O0 foo.c -o foo [regehr@bethe ~]$ ./foo 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 [regehr@bethe ~]$ icc -O foo.c -o foo [regehr@bethe ~]$ ./foo 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

जीसीसी का नवीनतम संस्करण (x86 के लिए 170512 का रिव्यू) एक स्थिर परिणाम देता है:

 regehr@home:~$ current-gcc -O0 foo.c -o foo regehr@home:~$ ./foo 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 regehr@home:~$ current-gcc -O2 foo.c -o foo regehr@home:~$ ./foo 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 

हालाँकि, यदि हम कंपाइलर को फंक्शन प्रतिस्थापन न करने के लिए कहें तो कहानी बदल जाती है:

 regehr@home:~$ current-gcc -O2 -fno-inline foo.c -o foo regehr@home:~$ ./foo 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

तब मैंने कॉम्पर्ट की कोशिश की और स्थिति ने एक अप्रत्याशित मोड़ लिया:

 regehr@home:~$ ccomp foo.c -o foo regehr@home:~$ ./foo 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 

यह बहुत अजीब है, क्योंकि कॉम्पर्ट में निहित सी भाषा रूपांतरणों का एक सिद्ध संस्करण है - यह उनके परीक्षण के लिए था कि foo() लिखा गया था।

संक्षेप में, जब से char प्रकार पहले से ही int प्रकार का है, और जब x साइन चार प्रकार का है और मान CHAR_MAX , ++x का व्यवहार स्पष्ट रूप से ANSI C और C99 दोनों मानकों द्वारा परिभाषित किया गया है।

1. मानक पढ़ता है: "अभिव्यक्ति ++E अभिव्यक्ति के बराबर है (E+=1) ।"
2. मानक पढ़ता है: " E1 op= E2 के रूप में यौगिक असाइनमेंट ऑपरेटर का उपयोग करना सामान्य असाइनमेंट E1 = E1 op (E2) से भिन्न होता है, केवल चर E1 गणना केवल एक बार की जाती है।"
3. असाइनमेंट एक्सप्रेशन " E1 op E2 " के दाईं ओर "सामान्य अंकगणितीय रूपांतरण" को संदर्भित करता है।
4. परम्परागत अंकगणितीय रूपांतरण का अर्थ है कि दोनों संचालकों को + संचालक के signed char से परिवर्तित प्रकार में परिवर्तित होने से पहले signed int से परिवर्तित किया जाना चाहिए।
5. चूंकि इंट चार से अधिक व्यापक है, इसलिए अंकगणितीय अतिप्रवाह का कोई मौका नहीं है।

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

 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 

दूसरे शब्दों में, परिणाम की गणना करने के लिए ++x > y जब दोनों चर प्रकार " signed char " के चर होते हैं और मूल्य CHAR_MAX :

1. हस्ताक्षरित चार 127 हस्ताक्षर किए गए int 127 में परिवर्तित हो जाते हैं;
2. हस्ताक्षरित इंट 127 एक की वृद्धि हुई, हस्ताक्षरित इंट 128 में बदल गया;
3. हस्ताक्षर किए गए int 128 को हस्ताक्षरित char -128 में बदल दिया जाता है - यह x का नया मान है और अभिव्यक्ति ++x (नोट: इस प्रकार का रूपांतरण मानक द्वारा परिभाषित नहीं है, लेकिन परिभाषित है और एक विशिष्ट कार्यान्वयन द्वारा स्पष्ट रूप से वर्णित किया जाना चाहिए);
4. हस्ताक्षरित char -128 हस्ताक्षरित int -128 में कनवर्ट करता है;
5. तुलना-हस्ताक्षरित int -128> हस्ताक्षरित int 127 रिटर्न " 0 "।

तो इस तथ्य के बारे में क्या है कि आमतौर पर उपयोग किए जाने वाले चार संकलक में से कोई भी सही परिणाम नहीं दिखाता है?

• जीसीसी में, एक बग जाना जाता है
• LLVM / Clang में, बग का पता नहीं था, लेकिन 24 घंटों के भीतर इसे ठीक कर दिया गया था ।
• इंटेल कंपाइलर में भी त्रुटि है।
• CompCert में कोई त्रुटि नहीं है। हालाँकि, अहस्ताक्षरित चार की अपनी परिभाषा और हस्ताक्षरित मान CHAR_MIN और CHAR_MAX की सीमाओं के बीच बातचीत की एक समस्या है। मेरे लिनक्स मशीन पर फ़ाइल में। कंपाइलर और उसके पूरे वातावरण (हेडर फाइल्स, लाइब्रेरी, असेम्बलर्स, इनपुट-आउटपुट प्रोसेस आदि) का सत्यापन एक गंभीर और खुली समस्या है। इसलिए हम परीक्षण लिखते हैं।

मूल लेख - blog.regehr.org/archives/482