सख्त अलियासिंग क्या है और हमें क्यों परवाह करनी चाहिए? भाग २

(या विचित्र टाइपिंग, अस्पष्ट व्यवहार और संरेखण, हे भगवान!)

दोस्तों, पाठ्यक्रम "C ++ डेवलपर" पर एक नए सूत्र के लॉन्च से पहले बहुत कम समय बचा है। यह सामग्री के दूसरे भाग के अनुवाद को प्रकाशित करने का समय है, जो बताता है कि एक वाक्य क्या टाइप कर रहा है।

एक दंड टंकण क्या है?

हम उस बिंदु पर पहुँच गए हैं जहाँ हम सोच सकते हैं कि हमें छद्म नामों की आवश्यकता क्यों हो सकती है? आमतौर पर दंड टाइपिंग के कार्यान्वयन के लिए, टी.के. अक्सर इस्तेमाल किए जाने वाले तरीके सख्त अलियासिंग नियमों का उल्लंघन करते हैं।



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

int x = 1 ; //   C float *fp = (float*)&x ; //   //  C++ float *fp = reinterpret_cast<float*>(&x) ; //   printf( “%f\n”, *fp ) ; 

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

 union u1 { int n; float f; } ; union u1 u; uf = 1.0f; printf( "%d\n”, un ); // UB(undefined behaviour)  C++ “n is not the active member” 

यह C ++ में अस्वीकार्य है, और कुछ का मानना ​​है कि यूनियनों का उद्देश्य केवल भिन्न प्रकारों को लागू करना है, और विचार करें कि टाइपिंग पैंट्स के लिए यूनियनों का उपयोग करना एक दुरुपयोग है।

सजा कैसे लागू करें?

C और C ++ में टाइपिंग पाइंट के लिए मानक धन्य विधि यादगार है। यह थोड़ा जटिल लग सकता है, लेकिन ऑप्टिमाइज़र को सजा के लिए मेमकी के उपयोग को पहचानने की आवश्यकता है, इसे अनुकूलित करें और इस कदम को पंजीकृत करने के लिए एक रजिस्टर उत्पन्न करें। उदाहरण के लिए, यदि हम जानते हैं कि int64_t दोहरे के समान आकार है:

 static_assert( sizeof( double ) == sizeof( int64_t ) ); // C++17    

हम memcpy उपयोग कर सकते हैं:

 void func1( double d ) { std::int64_t n; std::memcpy(&n, &d, sizeof d); //… 

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

पुं प्रकार और अर्र

लेकिन क्या होगा अगर हम अहस्ताक्षरित चार सरणी की सजा को अहस्ताक्षरित int की श्रृंखला में लागू करना चाहते हैं और फिर प्रत्येक अहस्ताक्षरित मान पर एक ऑपरेशन करते हैं? हम एक अप्रकाशित अंतर प्रकार में अहस्ताक्षरित चार सरणी को चालू करने के लिए मेम्पी का उपयोग कर सकते हैं। आशावादी अभी भी सब कुछ मेमसीपी के माध्यम से देख सकता है और अस्थायी वस्तु और प्रतिलिपि दोनों को अनुकूलित कर सकता है और अंतर्निहित डेटा ( उदाहरण ) के साथ सीधे काम कर सकता है:

 //  ,    int foo( unsigned int x ) { return x ; } // ,  len  sizeof(unsigned int) int bar( unsigned char *p, size_t len ) { int result = 0; for( size_t index = 0; index < len; index += sizeof(unsigned int) ) { unsigned int ui = 0; std::memcpy( &ui, &p[index], sizeof(unsigned int) ); result += foo( ui ) ; } return result; } 

इस उदाहरण में, हम char*p लेते हैं, यह मानते हैं कि यह sizeof(unsigned int) डेटा के कई टुकड़ों को इंगित करता है, डेटा के प्रत्येक टुकड़े को unsigned int रूप में व्याख्या करता है, सजा के प्रत्येक टुकड़े के लिए foo() गणना करें, इसे परिणाम में योग करें और अंतिम मूल्य लौटाएं। ।

लूप बॉडी के लिए असेंबली से पता चलता है कि ऑप्टिमाइज़र शरीर को unsigned char बेस सरणी में एक unsigned int रूप में सीधे पहुंच में बदल देता है, इसे सीधे eax जोड़ देता है:

 add eax, dword ptr [rdi + rcx] 

एक ही कोड, लेकिन एक वाक्य को लागू करने के लिए reinterpret_cast उपयोग कर (सख्त अलियासिंग का उल्लंघन करता है):

 // ,  len  sizeof(unsigned int) int bar( unsigned char *p, size_t len ) { int result = 0; for( size_t index = 0; index < len; index += sizeof(unsigned int) ) { unsigned int ui = *reinterpret_cast<unsigned int*>(&p[index]); result += foo( ui ); } return result; } 

C ++ 20 और bit_cast

C ++ 20 में, हमारे पास bit_cast , जो व्याख्या करने का एक आसान और सुरक्षित तरीका प्रदान करता है, और constexpr के संदर्भ में भी इस्तेमाल किया जा सकता है।

निम्नलिखित एक उदाहरण है कि कैसे एक float में अहस्ताक्षरित पूर्णांक की व्याख्या करने के लिए bit_cast का उपयोग किया bit_cast ( उदाहरण ):

 std::cout << bit_cast<float>(0x447a0000) << "\n" ; //,  sizeof(float) == sizeof(unsigned int) 

मामले में जब प्रकार और इससे आकार समान नहीं होता है, तो इसके लिए हमें एक मध्यवर्ती संरचना का उपयोग करना होगा। हम एक ऐसी संरचना का उपयोग करेंगे जिसमें अनेक प्रकार के sizeof(unsigned int) अक्षर sizeof(unsigned int) (एक 4-बाइट अहस्ताक्षरित int को मान लिया गया है) प्रकार से, और unsigned int को प्रकार के रूप में।

 struct uint_chars { unsigned char arr[sizeof( unsigned int )] = {} ; //  sizeof( unsigned int ) == 4 }; //  len  4 int bar( unsigned char *p, size_t len ) { int result = 0; for( size_t index = 0; index < len; index += sizeof(unsigned int) ) { uint_chars f; std::memcpy( f.arr, &p[index], sizeof(unsigned int)); unsigned int result = bit_cast<unsigned int>(f); result += foo( result ); } return result ; } 

दुर्भाग्य से, हमें इस मध्यवर्ती प्रकार की आवश्यकता है - यह वर्तमान bit_cast सीमा है।

संरेखण

पिछले उदाहरणों में, हमने देखा कि सख्त अलियासिंग नियमों के उल्लंघन से अनुकूलन के दौरान भंडारण बहिष्करण हो सकता है। सख्त अलियासिंग का उल्लंघन भी संरेखण आवश्यकताओं का उल्लंघन हो सकता है। सी मानकों और सी ++ दोनों का कहना है कि ऑब्जेक्ट्स संरेखण आवश्यकताओं के अधीन हैं जो उस स्थान को सीमित करते हैं जहां वस्तुओं को रखा जा सकता है (स्मृति में) और इसलिए सुलभ। C11 खंड 6.2.8 वस्तुओं का संरेखण राज्यों :

पूर्ण प्रकार की वस्तुओं में संरेखण आवश्यकताएँ होती हैं जो उन पतों पर प्रतिबंध लगाती हैं जिन पर इस प्रकार की वस्तुएँ रखी जा सकती हैं। संरेखण एक कार्यान्वयन-परिभाषित पूर्णांक मान है जो लगातार पते के बीच बाइट्स की संख्या का प्रतिनिधित्व करता है जिस पर यह ऑब्जेक्ट रखा जा सकता है। ऑब्जेक्ट प्रकार इस प्रकार के प्रत्येक ऑब्जेक्ट पर संरेखण की आवश्यकता को लगाता है: _Alignas का उपयोग करके अधिक कड़े संरेखण का अनुरोध किया जा सकता है।

धारा 1 में C ++ 17 परियोजना मानक [basic.align] :

ऑब्जेक्ट प्रकार में संरेखण आवश्यकताएँ (6.7.1, 6.7.2) होती हैं, जो उन पतों पर प्रतिबंध लगाती हैं जिन पर इस प्रकार की कोई वस्तु रखी जा सकती है। संरेखण एक कार्यान्वयन-परिभाषित पूर्णांक मूल्य है जो लगातार पते के बीच बाइट्स की संख्या का प्रतिनिधित्व करता है जिस पर किसी दिए गए ऑब्जेक्ट को रखा जा सकता है। एक वस्तु प्रकार इस प्रकार की प्रत्येक वस्तु पर एक संरेखण आवश्यकता लगाता है; संरेखण विनिर्देशक (10.6.2) का उपयोग करके अधिक कठोर संरेखण का अनुरोध किया जा सकता है।

C99 और C11 दोनों स्पष्ट रूप से इंगित करते हैं कि एक रूपांतरण जो एक बिना संकेत वाले सूचक के परिणामस्वरूप अपरिभाषित व्यवहार करता है, खंड 6.3.2.3। संकेत कहते हैं:

एक वस्तु या आंशिक प्रकार के लिए एक सूचक को एक अन्य वस्तु या आंशिक प्रकार के लिए एक सूचक में परिवर्तित किया जा सकता है। यदि परिणामी पॉइंटर को पॉइंटर प्रकार के लिए ठीक से संरेखित नहीं किया गया है, तो व्यवहार अपरिभाषित है। ...

हालाँकि C ++ इतना स्पष्ट नहीं है, मेरा मानना ​​है कि पैराग्राफ 1 [basic.align] से यह वाक्य पर्याप्त है:

... वस्तु का प्रकार इस प्रकार की प्रत्येक वस्तु पर एक संरेखण आवश्यकता लगाता है; ...

उदाहरण

तो चलिए मान लेते हैं:

• संरेखित करें (चार) और संरेखित (int) क्रमशः 1 और 4 हैं
• sizeof (int) 4 है

इस प्रकार, आकार 4 के एक चार सरणी की व्याख्या करना, जैसे कि सख्त अलियासिंग का उल्लंघन करता है, और संरेखण आवश्यकताओं का भी उल्लंघन कर सकता है यदि सरणी में 1 या 2 बाइट्स का संरेखण है।

 char arr[4] = { 0x0F, 0x0, 0x0, 0x00 }; //        1  2  int x = *reinterpret_cast<int*>(arr); // Undefined behavior   

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

 alignas(alignof(int)) char arr[4] = { 0x0F, 0x0, 0x0, 0x00 }; int x = *reinterpret_cast<int*>(arr); 

atomicity

असंतुलित पहुंच के लिए एक और अप्रत्याशित सजा यह है कि यह कुछ आर्किटेक्चर की परमाणुता का उल्लंघन करता है। अगर वे संरेखित नहीं हैं तो परमाणु स्टोर x86 में अन्य थ्रेड्स के लिए परमाणु दिखाई नहीं दे सकते हैं।

सख्त अलियासिंग उल्लंघन पकड़े

C ++ में सख्त अलियासिंग पर नज़र रखने के लिए हमारे पास कई अच्छे उपकरण नहीं हैं। हमारे पास जो उपकरण हैं वे उल्लंघन के कुछ मामलों और अनुचित लोडिंग और भंडारण के कुछ मामलों को पकड़ लेंगे।

-fstrict-aliasing और -Wstrict-aliasing झंडे का उपयोग करके कुछ मामलों को पकड़ सकते हैं, हालांकि झूठी सकारात्मक / परेशानियों के बिना नहीं। उदाहरण के लिए, निम्नलिखित मामले gcc ( उदाहरण ) में चेतावनी उत्पन्न करेंगे:

 int a = 1; short j; float f = 1.f; //   ,   TIS ,         printf("%i\n", j = *(reinterpret_cast<short*>(&a))); printf("%i\n", j = *(reinterpret_cast<int*>(&f))); 

हालाँकि वह इस अतिरिक्त मामले को नहीं पकड़ेगा ( उदाहरण ):

 int *p; p=&a; printf("%i\n", j = *(reinterpret_cast<short*>(p))); 

हालांकि clang इन झंडों को हल करता है, यह वास्तव में चेतावनी को लागू करने के लिए नहीं लगता है।

हमारे पास एक और उपकरण है आसन, जो गलत रिकॉर्डिंग और स्टोरेज को पकड़ सकता है। हालांकि वे सख्त अलियासिंग के सीधे उल्लंघन नहीं हैं, यह एक काफी सामान्य परिणाम है। उदाहरण के लिए, निम्न मामले असेंबली का उपयोग करके असेंबली के दौरान रनटाइम त्रुटियों को उत्पन्न करेंगे -fsanitize=address

 int *x = new int[2]; // 8 : [0,7]. int *u = (int*)((char*)x + 6); //     x    *u = 1; //    [6-9] printf( "%d\n", *u ); //    [6-9] 

अंतिम उपकरण जो मैं सुझाता हूं, वह C ++ के लिए विशिष्ट है और वास्तव में, न केवल एक उपकरण है, बल्कि एक कोडिंग अभ्यास भी है जो C- शैली की कास्टिंग की अनुमति नहीं देता है। दोनों gcc और -Wold-style-cast का उपयोग करके C -Wold-style-cast लिए निदान करेंगे। -Wold-style-cast । यह किसी भी अपरिभाषित टाइपिंग पुंज को reinterpret_cast का उपयोग करने के लिए मजबूर करेगा। सामान्य तौर पर, कोड के अधिक गहन विश्लेषण के लिए रीइंटरप्रिट_कास्ट एक बीकन होना चाहिए।
ऑडिट करने के लिए reinterpret_cast लिए कोडबेस खोजना आसान है।

C के लिए, हमारे पास पहले से वर्णित सभी उपकरण हैं, और हमारे पास tis-interpreter भी है, एक स्थैतिक विश्लेषक जो C के एक बड़े उपसमूह के लिए प्रोग्राम का विस्तृत विश्लेषण करता है, पिछले उदाहरण के C संस्करणों को देखते हुए, जहां -fstrict-aliasing skips एक मामले का उपयोग करता है। ( उदाहरण )

 int a = 1; short j; float f = 1.0 ; printf("%i\n", j = *((short*)&a)); printf("%i\n", j = *((int*)&f)); int *p; p=&a; printf("%i\n", j = *((short*)p)); 

TIS दुभाषिया तीनों को रोक सकता है, निम्न उदाहरण TIS कर्नेल को TIS दुभाषिया कहता है (आउटपुट को संक्षिप्तता के लिए संपादित किया जाता है):

 ./bin/tis-kernel -sa example1.c ... example1.c:9:[sa] warning: The pointer (short *)(& a) has type short *. It violates strict aliasing rules by accessing a cell with effective type int. ... example1.c:10:[sa] warning: The pointer (int *)(& f) has type int *. It violates strict aliasing rules by accessing a cell with effective type float. Callstack: main ... example1.c:15:[sa] warning: The pointer (short *)p has type short *. It violates strict aliasing rules by accessing a cell with effective type int. 

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

निष्कर्ष

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

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

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

इस लेख पर टिप्पणी करने वालों का धन्यवाद: जेएफ बास्टियन, क्रिस्टोफर डि बेला, पास्कल क्वोक, मैट पी। ड्ज़ुबिंस्की, पैट्रिस रॉय और ओलाफुर वेज
बेशक, अंत में, सभी त्रुटियाँ लेखक की हैं।

तो एक बड़ी सामग्री का अनुवाद समाप्त हो गया है, जिसका पहला भाग यहां पढ़ा जा सकता है । और हम परंपरागत रूप से आपको खुले दरवाजे के दिन के लिए आमंत्रित करते हैं , जो 14 मार्च को रामबलर एंड कंपनी - दिमित्री शबॉर्डेव में प्रौद्योगिकी विकास विभाग के प्रमुख द्वारा आयोजित किया जाएगा ।