2016-08-10 5 views
13

मज़बूत इंगित करता है इस सीमा से एक पढ़ा है कि:क्या strncmp के इस उपयोग में सीमाओं को पढ़ना शामिल है?

if (strncmp("test string", "less than 32 char", 32) == 0) 
{ 
... 
} 

इसे कहते समारोह less than 32 char की सीमा के बाहर से डेटा पढ़ता है।

क्या वास्तव में कोई खोज है यदि strncmp 32 वर्णों से अधिक हो जाता है और दूसरी स्ट्रिंग 32 वर्णों से कम है?

+2

फोर्टिफ़ा गलत है। कम से कम उचित के लिए, यह 'strncmp() 'के मानक अनुरूप कार्यान्वयन है। – alk

+1

जब तक कि मैं * बहुत * गलत नहीं हूं, 'strncmp()' को केवल आपके उदाहरण में प्रत्येक स्ट्रिंग से एक 'char' की तुलना करने की आवश्यकता होगी। मैं झूठी सकारात्मक दूसरी। – EOF

+0

कृपया एक [एमसीवी] प्रदान करें और देखें [पूछें]। इसमें फोर्टिफ़ाई का पुनर्मूल्यांकन शामिल होगा। या एचपी से पूछें कि यह आवश्यक जानकारी के साथ झूठी सकारात्मक क्यों उत्पन्न करता है। – Olaf

उत्तर

9

टी एल; डॉ - strncmp()स्ट्रिंग तत्वों की तुलना करें, तो या तो स्ट्रिंग या 32 तत्वों (पात्रों) के अंत तक, जो भी है कम तक रखेंगे।

ए (ny) स्ट्रिंग हमेशा अशक्त-समाप्त है और अशक्त-टर्मिनेटर का सामना करने पर, आगे कोई तुलना किया जाता है। आपका कोड सुरक्षित है।

C11 का हवाला देते हुए, अध्याय §7.24.4.4 (जोर मेरा)

int strncmp(const char *s1, const char *s2, size_t n); 

strncmp समारोह से अधिक नहीं n वर्ण (अक्षर हैं जो एक अशक्त चरित्र का पालन तुलना नहीं कर रहे हैं) तुलना सरणी से s1 पर सरणी से s2 पर इंगित किया गया है।

6

आपके पास पूरी तरह से वैध कोड है।

या तो आपका कंपाइलर खराब ऑब्जेक्ट कोड उत्पन्न कर रहा है या fortify झूठी सकारात्मक रिपोर्टिंग कर रहा है।

मुझे संदेह है कि यह संकलक खराब कोड उत्पन्न कर रहा है। इससे बहुत सारी समस्याएं पैदा होंगी और किसी भी समय पता लगाया जाएगा और तय किया जाएगा।

यह सबसे अधिक संभावना है कि किलेदारी झूठी सकारात्मक रिपोर्टिंग कर रही है।

+1

क्या खराब ऑब्जेक्ट कोड उत्पन्न करना? किस लिए? एक समारोह कॉल? एक मानक पुस्तकालय समारोह के लिए? यह एक स्रोत कोड विश्लेषण है। कंपाइलर या ऑब्जेक्ट कोड के साथ कुछ भी नहीं करना। – EJP

12

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

मैं दावा करता हूं कि इस तरह के कार्यान्वयन सी के रूप में कवर किए गए हैं, यानी, वे वैसे ही व्यवहार करते हैं जैसे वे "कार्यात्मक विनिर्देशों का पालन कर रहे थे।

ऐसे अनुकूलित कार्यान्वयन का एक उदाहरण OpenSolaris's strcmp() for SPARC v8 होगा। यह कोड है जिसे मैंने कुछ पंद्रह साल पहले लिखा था, साथ ही अन्य प्रदर्शन-अनुकूलित स्ट्रिंग फ़ंक्शंस के साथ।

विभिन्न मेमोरी चेकर उपकरण इस तरह के कोड के बारे में शिकायत करेंगे, हालांकि, इसका उपयोग आवंटित डेटा ऑब्जेक्ट की सीमाओं से परे पहुंच का कारण बन सकता है, भले ही आउट-ऑफ-बाउंड रीडिंग डिज़ाइन डिज़ाइन द्वारा हानिरहित हो।

+0

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

संबंधित मुद्दे