👩🏻‍🚀 🐏 👩🏽‍🏭 पीवीएस-स्टूडियो में झूठी सकारात्मक: खरगोश छेद कितना गहरा है 🧑🏻‍🤝‍🧑🏻 🌧️ 🕋

यूनिकॉर्न पीवीएस-स्टूडियो और गेटनामेडसिटीइन्फो

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

हम पीवीएस-स्टूडियो विश्लेषक द्वारा उत्पन्न झूठी सकारात्मक की संख्या को कम करने के लिए कड़ी मेहनत कर रहे हैं। दुर्भाग्य से, स्थैतिक विश्लेषक अक्सर त्रुटि से सही कोड को अलग नहीं कर सकते, क्योंकि उनके पास बस पर्याप्त जानकारी नहीं होती है। नतीजतन, वैसे भी झूठी सकारात्मकताएं हैं। हालांकि, यह कोई समस्या नहीं है, क्योंकि विश्लेषक के पास होने के बाद ऐसी स्थिति हासिल करना आसान है, जहां 10 में से 9 चेतावनियां कुछ गलतियां बताएंगी।

यद्यपि झूठी अलार्म इतनी बड़ी समस्या नहीं है क्योंकि यह पहली नज़र में लग सकता है, हम लगातार उनके साथ संघर्ष कर रहे हैं, निदान में सुधार कर रहे हैं। हम स्वयं कुछ झूठे सकारात्मक लोगों को नोटिस करते हैं, जिनमें से कुछ ग्राहकों और मुफ्त उपयोगकर्ताओं द्वारा हमें लिखे गए हैं।

हाल ही में, हमारे ग्राहकों में से एक ने लगभग निम्नलिखित सामग्री का एक पत्र लिखा था:

किसी कारण से, विश्लेषक का कहना है कि सूचक हमेशा शून्य है, हालांकि यह स्पष्ट रूप से ऐसा नहीं है। इसके अलावा, विश्लेषक एक परीक्षण परियोजना पर अजीब और अस्थिर व्यवहार करता है: यह या तो एक चेतावनी जारी करता है, या यह नहीं करता है। एक सिंथेटिक उदाहरण जो एक झूठे सकारात्मक को पुन: पेश करता है:

#include <windows.h> #include <aclapi.h> #include <tchar.h> int main() { PACL pDACL = NULL; PSECURITY_DESCRIPTOR pSD = NULL; ::GetNamedSecurityInfo(_T("ObjectName"), SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, &pDACL, NULL, &pSD); auto test = pDACL == NULL; // V547 Expression 'pDACL == 0' is always true. return 0; }

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

एह ... स्थैतिक कोड विश्लेषक बनाए रखना आसान काम नहीं है। लेकिन क्या करूं, मैंने खुद ऐसी किस्मत चुनी। अपनी आस्तीन को रोल करते हुए, मैं झूठे सकारात्मक के कारण की जांच करने के लिए आगे बढ़ा।

इसके साथ शुरू करने के लिए, मैंने GetNamedSecurityInfo फ़ंक्शन के विवरण का अध्ययन किया और यह सुनिश्चित किया कि इसके कॉल को वास्तव में pDACL वैरिएबल के मूल्य में बदलाव का नेतृत्व करना चाहिए। यहां 6 वें फ़ंक्शन तर्क का विवरण दिया गया है:

ppDacl

एक वैरिएबल का एक पॉइंटर जो लौटाए गए सुरक्षा डिस्क्रिप्टर या NULL में DACL को एक पॉइंटर प्राप्त करता है यदि सुरक्षा डिस्क्रिप्टर में कोई DACL नहीं है। यदि आप DACL_SECURITY_INFORMATION ध्वज सेट करते हैं, तो लौटा हुआ सूचक मान्य है। साथ ही, यह पैरामीटर NULL हो सकता है यदि आपको DACL की आवश्यकता नहीं है।

मुझे पता है कि पीवीएस-स्टूडियो विश्लेषक को निश्चित रूप से ऐसे सरल कोड को सही ढंग से संसाधित करना चाहिए और अर्थहीन चेतावनी नहीं देना चाहिए। पहले से ही इस समय, मेरे अंतर्ज्ञान ने मुझे बताया कि यह एक असामान्य मामला होगा, जिसमें समय बिताना होगा।

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

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

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

वास्तव में ये क्यों? मुझे अच्छी तरह से पता है कि V547 के विश्लेषक और निदान कैसे काम करते हैं । खैर, ऐसी कोई सक्रियता नहीं हो सकती है!

ठीक है, चाय बनाओ और जारी रखो।

GetNamedSecurityInfo फ़ंक्शन के लिए कॉल का विस्तार होता है:

 ::GetNamedSecurityInfoW(L"ObjectName", SE_FILE_OBJECT, (0x00000004L), 0, 0, &pDACL, 0, &pSD);

यह कोड मेरी प्रीप्रोसेस की गई आई-फाइल और क्लाइंट द्वारा भेजी गई फाइल दोनों में समान है।

हम्म ... ठीक है, अब हम जांचेंगे कि यह फ़ंक्शन कैसे घोषित किया गया है। मेरी फ़ाइल में मैं देख रहा हूँ:

 __declspec(dllimport) DWORD __stdcall GetNamedSecurityInfoW( LPCWSTR pObjectName, SE_OBJECT_TYPE ObjectType, SECURITY_INFORMATION SecurityInfo, PSID * ppsidOwner, PSID * ppsidGroup, PACL * ppDacl, PACL * ppSacl, PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

सब कुछ तार्किक है, सब कुछ स्पष्ट है। कुछ भी अप्रत्याशित नहीं है।

अगला, मैं ग्राहक फ़ाइल को देखता हूं और ...

वहाँ मैं समानांतर वास्तविकता से कुछ देखता हूँ:

 __declspec(dllimport) DWORD __stdcall GetNamedSecurityInfoW( LPCWSTR pObjectName, SE_OBJECT_TYPE ObjectType, SECURITY_INFORMATION SecurityInfo, const PSID * ppsidOwner, const PSID * ppsidGroup, const PACL * ppDacl, const PACL * ppSacl, PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

ध्यान दें कि ppDacl के लिए औपचारिक तर्क को कास्ट के रूप में चिह्नित किया गया है।

WAT? WTF? WAT? WTF?

क्या कमी है ? वह कहाँ से है ?!

कम से कम यह तुरंत स्पष्ट है कि विश्लेषक को यहां दोष नहीं देना है और मैं उनके सम्मान की रक्षा कर सकता हूं।

तर्क एक स्थिर वस्तु का सूचक है। यह पता चला है कि, विश्लेषक के दृष्टिकोण से, GetNamedSecurityInfoW फ़ंक्शन पॉइंटर को संदर्भित ऑब्जेक्ट को बदल नहीं सकता है। इसलिए यहाँ:

 PACL pDACL = NULL; PSECURITY_DESCRIPTOR pSD = NULL; ::GetNamedSecurityInfo(_T("ObjectName"), SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, &pDACL, NULL, &pSD); auto test = pDACL == NULL; // V547 Expression 'pDACL == 0' is always true.

pDACL चर नहीं बदल सकता है और विश्लेषक एक उचित चेतावनी (अभिव्यक्ति 'pDACL == 0 हमेशा सही है) उत्पन्न करता है।

चेतावनी क्यों जारी की जाती है, यह समझा जा सकता है। लेकिन यह स्पष्ट नहीं है कि यह कांस्टेबल कहां से आया था। यह सिर्फ वहाँ नहीं हो सकता!

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

तो, एक बार aclapi.h फ़ाइल में एक फ़ंक्शन विवरण था (6.0.6002.18005-Windows 6.0):

 WINADVAPI DWORD WINAPI GetNamedSecurityInfoW( __in LPWSTR pObjectName, __in SE_OBJECT_TYPE ObjectType, __in SECURITY_INFORMATION SecurityInfo, __out_opt PSID * ppsidOwner, __out_opt PSID * ppsidGroup, __out_opt PACL * ppDacl, __out_opt PACL * ppSacl, __out_opt PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

तब कोई व्यक्ति औपचारिक तर्क pObjectName के प्रकार को ठीक करना चाहता था, लेकिन जिस तरह से लिखने के साथ संकेत के प्रकार गड़बड़ कर दिए। और aclapi.h (6.1.7601.23418-Windows 7.0) इस तरह बन गया:

 WINADVAPI DWORD WINAPI GetNamedSecurityInfoW( __in LPCWSTR pObjectName, __in SE_OBJECT_TYPE ObjectType, __in SECURITY_INFORMATION SecurityInfo, __out_opt const PSID * ppsidOwner, __out_opt const PSID * ppsidGroup, __out_opt const PACL * ppDacl, __out_opt const PACL * ppSacl, __out PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

यह स्पष्ट हो जाता है कि यह ठीक गलत गलत aclapi.h फ़ाइल है जो क्लाइंट द्वारा उपयोग की जाती है। बाद में उन्होंने पत्राचार में इस परिकल्पना की पुष्टि की। मैं अधिक हाल के संस्करण का उपयोग करता हूं, इसलिए त्रुटि पुन: उत्पन्न नहीं हुई।

यहाँ aclapi.h (6.3.9600.17415-Windows_8.1) में पहले से ठीक किया गया फ़ंक्शन वर्णन कैसा दिखता है।

 WINADVAPI DWORD WINAPI GetNamedSecurityInfoW( _In_ LPCWSTR pObjectName, _In_ SE_OBJECT_TYPE ObjectType, _In_ SECURITY_INFORMATION SecurityInfo, _Out_opt_ PSID * ppsidOwner, _Out_opt_ PSID * ppsidGroup, _Out_opt_ PACL * ppDacl, _Out_opt_ PACL * ppSacl, _Out_ PSECURITY_DESCRIPTOR * ppSecurityDescriptor );

तर्क प्रकार pObjectName समान रहा, लेकिन अतिरिक्त कास्ट हटा दिया गया था। सब कुछ अपने स्थानों पर लौट आया है, लेकिन गलत फ़ंक्शन घोषणाओं वाली हेडर फाइलें दुनिया में रहती हैं।

यह सब मैं क्लाइंट को बताता हूं। वह प्रसन्न और प्रसन्न है कि स्थिति साफ हो गई है। इसके अलावा, वह इस कारण का पता लगाता है कि वह या तो झूठे सकारात्मक को देखता है या नहीं:

मैं भूल गया कि मैंने एक बार इस परीक्षण परियोजना पर टूलसेट के साथ प्रयोग किया था। डीबग टेस्ट प्रोजेक्ट में, कॉन्फ़िगरेशन को Visual Studio 2017 - "Visual Studio 2017 (v141)" के लिए डिफ़ॉल्ट रूप से प्लेटफ़ॉर्म टूलसेट पर कॉन्फ़िगर किया गया है, लेकिन रिलीज़ कॉन्फ़िगरेशन "Visual Studio 2015 - Windows XP (v140_xp)" पर कॉन्फ़िगर किया गया है। कल, मैंने कुछ बिंदु पर कॉन्फ़िगरेशन को बदल दिया, और चेतावनी दिखाई दी और गायब हो गई।

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

निष्कर्ष

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

हमारे ग्राहक बनें और आप मुझे और मेरे सहयोगियों से तेजी से, गुणवत्ता का समर्थन प्राप्त करेंगे।

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

पीवीएस-स्टूडियो में झूठी सकारात्मक: खरगोश छेद कितना गहरा है

More articles: