C में संकेत आपके विचार से अधिक सार हैं

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

कुछ समय बाद, हैबे पर अनुवाद के प्रकाशन के बाद, लेखक ने लेख के पाठ में बड़े संशोधन किए। Habré पर अनुवाद को अपडेट करना एक अच्छा विचार नहीं है, क्योंकि कुछ टिप्पणियां अपना अर्थ खो देंगी या जगह से बाहर देख लेंगी। मैं पाठ को एक नए लेख के रूप में प्रकाशित नहीं करना चाहता। इसलिए, हमने सिर्फ viva64.com पर लेख के अनुवाद को अपडेट किया , और यहां हमने सब कुछ छोड़ दिया जैसा कि यह है। यदि आप एक नए पाठक हैं, तो मैं ऊपर दिए गए लिंक पर क्लिक करके हमारी साइट पर एक और हालिया अनुवाद पढ़ने का सुझाव देता हूं।

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

#include <stdio.h> int main(void) { int a, b; int *p = &a; int *q = &b + 1; printf("%p %p %d\n", (void *)p, (void *)q, p == q); return 0; } 

यदि हम इस GCC कोड को अनुकूलन स्तर 1 के साथ संकलित करते हैं और लिनक्स x86-64 के तहत प्रोग्राम चलाते हैं, तो यह निम्नलिखित प्रिंट करेगा:

 0x7fff4a35b19c 0x7fff4a35b19c 0 

ध्यान दें कि पॉइंटर्स p और q एक ही पते पर संदर्भित होते हैं। हालांकि, अभिव्यक्ति p == q का परिणाम गलत है , और यह पहली नज़र में अजीब लगता है। क्या एक ही पते के दो संकेत समान नहीं होने चाहिए?

यहाँ बताया गया है कि C मानक समानता के लिए दो बिंदुओं की जाँच के परिणाम को कैसे परिभाषित करता है:

C11 .9 6.5.9 पैरा 6 दो पॉइंटर्स समान हैं यदि और केवल यदि दोनों शून्य हैं, या तो एक ही ऑब्जेक्ट को इंगित करते हैं (ऑब्जेक्ट के लिए एक पॉइंटर सहित और ऑब्जेक्ट की संरचना में पहला सबोबेज) या एक फ़ंक्शन, या सरणी के अंतिम तत्व के बाद स्थिति को इंगित करता है, या एक पॉइंटर सरणी के अंतिम तत्व के बाद की स्थिति को संदर्भित करता है, और दूसरे को उसी पता स्थान में पहले के तुरंत बाद दूसरे सरणी की शुरुआत को संदर्भित करता है।

सबसे पहले, सवाल उठता है: एक "वस्तु " क्या है? चूँकि हम C भाषा के बारे में बात कर रहे हैं, इसलिए यह स्पष्ट है कि यहाँ वस्तुओं का OOP भाषाओं में C ++ जैसी वस्तुओं से कोई लेना-देना नहीं है। सी मानक में, यह अवधारणा पूरी तरह से परिभाषित नहीं है:

C11 15 3.15 ऑब्जेक्ट एक रनटाइम स्टोरेज एरिया होता है, जिसकी सामग्री का उपयोग मूल्यों को दर्शाने के लिए किया जा सकता है नोट जब उल्लेख किया गया है, तो एक वस्तु को एक विशिष्ट प्रकार के रूप में माना जा सकता है; देखें 6.3.2.1।

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

जब कंपाइलर रास्ते में मिल जाता है

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

C11 § 6.5.6 खंड 7 जब इन ऑपरेटरों के साथ प्रयोग किया जाता है, तो एक ऑब्जेक्ट के लिए एक पॉइंटर जो कि एलीमेंट का एक तत्व नहीं है, एक एलीमेंट के लिए एक एलीमेंट की तरह एक एलीमेंट की लंबाई के साथ व्यवहार करता है, जिसमें से टाइप ओरिजिनल ऑब्जेक्ट के प्रकार से मेल खाता है।

चूँकि किसी भी ऑब्जेक्ट के लिए कोई पॉइंटर जो कि एक एरे नहीं है वास्तव में एक एलीमेंट में एक एलीमेंट की लंबाई के साथ एक एलीमेंट के लिए एक पॉइंटर बन जाता है, मानक अरिथमेटिक को एड्रेस को केवल एरे के लिए परिभाषित करता है - यह पॉइंट 8 है। हम निम्नलिखित भाग में रुचि रखते हैं:

C11 § 6.5.6 खंड 8 यदि पूर्णांक अभिव्यक्ति को सूचक से जोड़ा या घटाया जाता है, तो परिणामी सूचक मूल सूचक के समान प्रकार का होता है। यदि स्रोत सूचक एक सरणी तत्व को संदर्भित करता है और सरणी पर्याप्त लंबाई का है, तो स्रोत और परिणामी तत्व एक दूसरे से अलग हो जाते हैं ताकि उनके सूचकांकों के बीच का अंतर पूर्णांक अभिव्यक्ति के मूल्य के बराबर हो। दूसरे शब्दों में, यदि अभिव्यक्ति P , सरणी के ith तत्व की ओर इंगित करता है, तो भाव (P) + N (या इसके समतुल्य N + (P) ) और (P) -N (जहाँ N का मान n है) क्रमशः इंगित करता है (i + n) वें और (i - n) सरणी के तत्व, बशर्ते कि वे मौजूद हों। इसके अलावा, यदि अभिव्यक्ति P सरणी के अंतिम तत्व को इंगित करता है, तो अभिव्यक्ति (P) +1 सरणी के अंतिम तत्व के बाद स्थिति को इंगित करता है, और यदि अभिव्यक्ति Q सरणी के अंतिम तत्व के बाद की स्थिति को इंगित करता है, तो अभिव्यक्ति (Q) -1 अंतिम तत्व को इंगित करता है। सरणी। यदि स्रोत और परिणामी संकेत दोनों सरणी के अंतिम तत्व के बाद उसी सरणी के तत्वों या स्थिति को संदर्भित करते हैं, तो अतिप्रवाह को बाहर रखा गया है; अन्यथा, व्यवहार अपरिभाषित है। यदि परिणामी सूचक सरणी के अंतिम तत्व के बाद की स्थिति को संदर्भित करता है, तो यूनरी * ऑपरेटर इसे लागू नहीं किया जा सकता है।

यह निम्नानुसार है कि अभिव्यक्ति और बी + 1 का परिणाम निश्चित रूप से एक पता होना चाहिए, और इसलिए पी और क्यू वैध संकेत हैं। मुझे याद दिलाएं कि मानक में दो बिंदुओं की समानता कैसे परिभाषित की गई है: " दो बिंदु समान हैं यदि और केवल अगर [...] एक सूचक सरणी के अंतिम तत्व के बाद की स्थिति को संदर्भित करता है, और दूसरे को सरणी के तुरंत बाद दूसरे सरणी की शुरुआत के समान है। पता स्थान " (C11 (6.5.9 खंड 6)। यह वही है जो हम अपने उदाहरण में देखते हैं। पॉइंटर क्यू, ऑब्जेक्ट बी के बाद की स्थिति को संदर्भित करता है, तुरंत ऑब्जेक्ट ए, जिसके बाद पॉइंटर पी को संदर्भित करता है। तो, क्या जीसीसी में एक बग है? इस विरोधाभास को 2014 में बग # 61502 के रूप में वर्णित किया गया था, लेकिन जीसीसी डेवलपर्स इसे बग नहीं मानते हैं और इसलिए इसे ठीक करने नहीं जा रहे हैं।

2016 में लिनक्स प्रोग्रामर द्वारा एक समान समस्या का सामना किया गया था। निम्नलिखित कोड पर विचार करें:

 extern int _start[]; extern int _end[]; void foo(void) { for (int *i = _start; i != _end; ++i) { /* ... */ } } 

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

समाधान - बग रिपोर्ट # 260 में?

हमारा मामला बग रिपोर्ट # 260 स्पष्ट कर सकता है। यह अनिश्चित मूल्यों के बारे में अधिक है, लेकिन आप इसमें समिति से एक जिज्ञासु टिप्पणी पा सकते हैं:

कंपाइलर कार्यान्वयन [...] अलग-अलग ऑब्जेक्ट से प्राप्त पॉइंटर्स को भी अलग कर सकता है, भले ही इन पॉइंटर्स में बिट्स का एक ही सेट हो।

यदि हम इस टिप्पणी को शाब्दिक रूप से लेते हैं, तो यह तर्कसंगत है कि अभिव्यक्ति p == q का परिणाम "गलत" है, क्योंकि p और q विभिन्न वस्तुओं से प्राप्त होते हैं जो किसी भी तरह से जुड़े नहीं हैं। ऐसा लगता है कि हम सच के करीब हो रहे हैं - या नहीं? अब तक, हमने समानता ऑपरेटरों के साथ काम किया है, लेकिन संबंध ऑपरेटरों के बारे में क्या?

अंतिम संविदा संबंध संचालकों में है?

सूचक तुलनाओं के संदर्भ में < , <= , > और > = संबंध ऑपरेटरों की परिभाषा में एक जिज्ञासु विचार है:

C11 .8 6.5.8 पैरा 5 दो बिंदुओं की तुलना करने का परिणाम पता स्थान में संकेतित वस्तुओं की सापेक्ष स्थिति पर निर्भर करता है। यदि दो प्रकार के ऑब्जेक्ट के प्रकार एक ही ऑब्जेक्ट को संदर्भित करते हैं, या दोनों समान सरणी के अंतिम तत्व के बाद स्थिति को संदर्भित करते हैं, तो ऐसे पॉइंटर्स समान हैं। यदि संकेतित वस्तुएं एक ही संयुक्त वस्तु के सदस्य हैं, तो बाद में घोषित संरचना के सदस्यों को इंगित करने वाले सदस्य पहले घोषित किए गए सदस्यों की तुलना में अधिक हैं, और उच्च सूचकांकों वाले एक सरणी के तत्वों के संकेत निम्न सूचकांकों के समान सरणी के तत्वों की तुलना में अधिक हैं। एक ही एसोसिएशन के सदस्यों के सभी संकेत समान हैं। यदि अभिव्यक्ति P सरणी के एक तत्व को इंगित करता है, और अभिव्यक्ति Q उसी सरणी के अंतिम तत्व को इंगित करता है, तो सूचक-अभिव्यक्ति Q + 1 का मान P के मान से अधिक होता है । अन्य सभी मामलों में, व्यवहार परिभाषित नहीं है।

इस परिभाषा के अनुसार, पॉइंटर्स की तुलना करने का परिणाम केवल तभी निर्धारित किया जाता है जब पॉइंटर्स को उसी ऑब्जेक्ट से प्राप्त किया जाता है । हम इसे दो उदाहरणों के साथ दिखाते हैं।

 int *p = malloc(64 * sizeof(int)); int *q = malloc(64 * sizeof(int)); if (p < q) //   foo(); 

यहाँ, पॉइंटर्स p और q दो अलग-अलग ऑब्जेक्ट्स को संदर्भित करते हैं जो आपस में जुड़े हुए नहीं हैं। इसलिए, उनकी तुलना के परिणाम को परिभाषित नहीं किया गया है। लेकिन निम्नलिखित उदाहरण में:

 int *p = malloc(64 * sizeof(int)); int *q = p + 42; if (p < q) foo(); 

पॉइंटर्स p और q एक ही ऑब्जेक्ट को संदर्भित करते हैं और इसलिए, आपस में जुड़े होते हैं। इसलिए, उनकी तुलना की जा सकती है - जब तक कि मलॉक एक शून्य मान नहीं लौटाता।

सारांश

C11 मानक सूचक तुलनाओं का पर्याप्त वर्णन नहीं करता है। सबसे अधिक समस्याग्रस्त बिंदु जो हमें मिला, वह पैरा 6, 6.5.9 था, जहां दो अलग-अलग सरणियों के संदर्भ में दो बिंदुओं की तुलना करने की स्पष्ट रूप से अनुमति दी गई है। यह बग रिपोर्ट # 260 की टिप्पणी का खंडन करता है। हालांकि, वहां हम अनिश्चित अर्थों के बारे में बात कर रहे हैं, और मैं अकेले इस टिप्पणी के आधार पर अपने तर्क का निर्माण नहीं करना चाहता हूं और इसे दूसरे संदर्भ में व्याख्या करना चाहता हूं। पॉइंटर्स की तुलना करते समय, रिलेशनशिप ऑपरेटर्स को समानता ऑपरेटरों की तुलना में थोड़ा अलग तरीके से परिभाषित किया जाता है - अर्थात, रिलेशनशिप ऑपरेटर्स को केवल तभी परिभाषित किया जाता है जब दोनों पॉइंटर्स एक ही ऑब्जेक्ट से प्राप्त किए जाते हैं।

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

हालांकि, सामान्य तौर पर, मैं C11 मानक में शब्दांकन से संतुष्ट नहीं हूं, और चूंकि कई लोग पहले ही इस समस्या का सामना कर चुके हैं, इसलिए यह सवाल बना हुआ है: नियमों को अधिक स्पष्ट रूप से क्यों नहीं बनाया जाए?

इसके अलावा
व्यूह के अंतिम तत्व के बाद स्थिति की ओर संकेत करता है

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

 const int num = 64; int x[num]; for (int *i = x; i < &x[num]; ++i) { /* ... */ } 

एक लूप का उपयोग करते हुए, हम 64 तत्वों से मिलकर पूरे एक्स सरणी पर जाते हैं, अर्थात्। लूप बॉडी को ठीक 64 बार निष्पादित करना चाहिए। लेकिन वास्तव में, स्थिति को 65 बार जांचा जाता है - सरणी में तत्वों की संख्या से एक बार अधिक। पहले 64 पुनरावृत्तियों में, सूचक i हमेशा सरणी x के अंदर को संदर्भित करता है, जबकि अभिव्यक्ति और x [संख्या] हमेशा सरणी के अंतिम तत्व के बाद स्थिति को इंगित करता है। 65 वें पुनरावृत्ति पर, सूचक i भी सरणी x के अंत से परे स्थिति को संदर्भित करेगा, क्योंकि लूप की स्थिति झूठी है। यह संपूर्ण सरणी को बायपास करने का एक सुविधाजनक तरीका है, और यह अन्य बिंदुओं की तुलना करते समय व्यवहार में अनिश्चितता के नियम के अपवाद पर निर्भर करता है। ध्यान दें कि मानक केवल बिंदुओं की तुलना करते समय व्यवहार का वर्णन करता है; dereferencing एक अलग मुद्दा है।

क्या हमारे उदाहरण को बदलना संभव है ताकि सरणी एक्स के अंतिम तत्व के बाद एक भी पॉइंटर स्थिति को संदर्भित न करे? यह संभव है, लेकिन यह अधिक कठिन होगा। हमें लूप की स्थिति को बदलना होगा और अंतिम पुनरावृत्ति पर चर i की वृद्धि को रोकना होगा।

 const int num = 64; int x[num]; for (int *i = x; i <= &x[num-1]; ++i) { /* ... */ if (i == &x[num-1]) break; } 

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

पीवीएस-स्टूडियो टीम नोट

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

लेख पहली बार stefansf.de पर अंग्रेजी में प्रकाशित हुआ था। लेखक की अनुमति से अनुवाद प्रकाशित किए जाते हैं।