🥀 🙌🏽 🕴🏾 VirtualDub की जाँच करें 😮 🕴🏼 😀

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

मैंने VirtualDub वेबसाइट से VirtualDub-1.10.3-src.7z संग्रह डाउनलोड किया है। विश्लेषण के लिए, मैंने पीवीएस-स्टूडियो संस्करण 5.10 का उपयोग किया। मैंने विश्लेषण पर लगभग एक घंटा बिताया, इसलिए सख्ती से न्याय न करें। निश्चित रूप से, मुझे कुछ याद आया। और इसके विपरीत, मैं सही कोड को संदिग्ध मान सकता था। मैं उन लोगों से पूछता हूं जो वर्चुअलडब परियोजना का समर्थन करते हैं जो मेरी रिपोर्ट पर भरोसा नहीं करते हैं, लेकिन एक स्वतंत्र जांच करने के लिए। हम हमेशा ओपन-सोर्स समुदाय से मिलने के लिए जाते हैं और पंजीकरण कुंजी आवंटित करने के लिए तैयार हैं।

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

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

हालांकि, यह लेख त्रुटियों के बारे में है, न कि स्थैतिक विश्लेषण का उपयोग करने की पद्धति। चलिए देखते हैं कि VirtualDub में क्या नया दिलचस्प PVS-Studio विश्लेषक मिला।

आभासी विध्वंसक

C ++ प्रोग्रामिंग लैंग्वेज में पॉलिमॉर्फिक बेस क्लास के डिस्ट्रक्टर को वर्चुअल घोषित किया जाना चाहिए। यह एक ही वर्ग के एक ऑब्जेक्ट के सही विनाश को सुनिश्चित करने का एकमात्र तरीका है जो एक संकेतक के माध्यम से संबंधित बेस क्लास के लिए होता है।

मुझे पता है कि सभी जानते हैं। हालांकि, यह विध्वंसक आभासी घोषित करने के लिए भूलना बंद नहीं करता है।

VirtualDub में VDDialogBaseW32 वर्ग है:

class VDDialogBaseW32 { .... ~VDDialogBaseW32(); .... virtual INT_PTR DlgProc(....) = 0; virtual bool PreNCDestroy(); .... }

जैसा कि आप देख सकते हैं, इसमें वर्चुअल फ़ंक्शंस हैं। हालांकि, विध्वंसक को आभासी घोषित नहीं किया जाता है। स्वाभाविक रूप से, उसे कक्षाएं विरासत में मिली हैं। उदाहरण के लिए, VDDialogAudioFilterFormatConvConfig:

 class VDDialogAudioFilterFormatConvConfig : public VDDialogBaseW32 { .... };

ऑब्जेक्ट विनाश त्रुटि इस तरह दिखती है:

 INT_PTR CALLBACK VDDialogBaseW32::StaticDlgProc(....) { VDDialogBaseW32 *pThis = (VDDialogBaseW32 *)GetWindowLongPtr(hwnd, DWLP_USER); .... delete pThis; .... }

PVS-Studio द्वारा जारी चेतावनी: V599 विध्वंसक को आभासी घोषित नहीं किया गया था, हालांकि 'VDDialogBaseW32' वर्ग में वर्चुअल फ़ंक्शंस होते हैं। VirtualDub gui.cpp 997

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

एक समान दुर्भाग्य VDMPEGAudioPolyphaseFilter वर्ग के साथ मौजूद है।

अस्पष्ट व्यवहार के बारे में अधिक

वर्चुअल डिस्ट्रक्टर से संबंधित त्रुटियों के बारे में कोई प्रश्न नहीं हैं। एक बहुत अधिक फिसलन विषय पारी संचालन है। यहाँ एक ऐसा उदाहरण है:

 void AVIVideoGIFOutputStream::write(....) { { .... for(int i=0; i<palsize; ++i) dict[i].mPrevAndLastChar = (-1 << 16) + i; .... }

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

पारी संचालक << और >> समूह बाएं से दाएं।

पारी-अभिव्यक्ति << योगात्मक-अभिव्यक्ति

पारी-अभिव्यक्ति >> योगात्मक-अभिव्यक्ति

ऑपरेंड अभिन्न या अनकैप्ड एन्यूमरेशन प्रकार के होंगे और इंटीग्रल प्रमोशन किए जाते हैं।

1. परिणाम का प्रकार प्रचारित बाएं ऑपरेंड है। यह व्यवहार अपरिभाषित है यदि सही ऑपरेंड नकारात्मक है, या पदोन्नत किए गए बाएं ऑपरेंड के बिट्स में लंबाई से अधिक या उसके बराबर है।

2. E1 का मान << E2 E1 बाएं-शिफ्ट किया गया E2 सा स्थान है; खाली बिट्स शून्य से भरे हुए हैं। यदि E1 में एक अहस्ताक्षरित प्रकार है, तो परिणाम का मान E1 * 2 ^ E2 है, परिणाम प्रकार में अधिकतम मूल्य प्रतिनिधित्व योग्य से एक से कम modulo। अन्यथा, यदि E1 में एक हस्ताक्षरित प्रकार और गैर-नकारात्मक मूल्य है, और E1 * 2 ^ E2 परिणाम प्रकार में प्रतिनिधित्व करने योग्य है, तो यह परिणामी मूल्य है; अन्यथा, व्यवहार अपरिभाषित है।

3. E1 >> E2 का मान E1 सही-स्थानांतरित E2 बिट स्थिति है। यदि E1 में एक अहस्ताक्षरित प्रकार है या यदि E1 में एक हस्ताक्षरित प्रकार और एक गैर-नकारात्मक मूल्य है, तो परिणाम का मान E1 / 2 ^ E2 के भागफल का अभिन्न अंग है । यदि ई 1 में एक हस्ताक्षरित प्रकार और एक नकारात्मक मूल्य है, तो परिणामस्वरूप मूल्य कार्यान्वयन-परिभाषित है।

कोड काम करता है भाग्य। अनुकूलन के लिए एक नया संकलक या अन्य कुंजियों में महारत हासिल करने पर, प्रोग्राम अप्रत्याशित रूप से अपने व्यवहार को बदल सकता है। शिफ्ट के बारे में अधिक पढ़ें और यह कोड को संपादित करने के लायक है या नहीं, आप लेख में पढ़ सकते हैं " कांटा नहीं जानते, पानी में नहीं उतरें। भाग तीन ।"

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

शुद्धिपत्र

 static ModuleInfo *CrashGetModules(void *&ptr) { .... while(*pszHeap++); if (pszHeap[-1]=='.') period = pszHeap-1; .... }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V529 Odd अर्धविराम ';) 'जबकि' ऑपरेटर के बाद। VirtualDub क्रैश। क्रैक 462

'जबकि' के बाद अर्धविराम पर ध्यान दें। यहां या तो त्रुटि या कोड को गलत तरीके से स्वरूपित किया गया है। मुझे लगता है कि यह बिल्कुल गलती है। लूप "जबकि (* pszHeap ++);" लाइन के अंत में जाएगा और इसके परिणामस्वरूप, चर 'pszHeap' टर्मिनल शून्य के बाद मेमोरी को इंगित करेगा। "If (pszHeap [-1] == ')'" की जाँच करने से कोई मतलब नहीं है। पता pszHeap [-1] में हमेशा एक टर्मिनल शून्य होता है।

तार के साथ काम करते समय एक और टाइपो पर विचार करें।

 void VDBackfaceService::Execute(...., char *s) { .... if (*s == '"') { while(*s && *s != '"') ++s; } else { .... }

पीवीएस-स्टूडियो द्वारा जारी किए गए नैदानिक संदेश: वी 637 दो विपरीत परिस्थितियों का सामना करना पड़ा। दूसरी शर्त हमेशा झूठी होती है। चेक लाइन: 183, 184। VirtualDub backface.cpp 183

इस कोड को उद्धरण चिह्नों में सब कुछ छोड़ देना चाहिए। कम से कम यह मुझे कैसा लगता है। हालाँकि, स्थिति (* s && * s! = '' ') तुरंत गलत है। शायद कोड को इस तरह देखा जाना चाहिए।

 if (*s == '"') { ++s; while(*s && *s != '"') ++s; }

नया ऑपरेटर अपवादों को फेंकता है जब स्मृति आबंटन विफल हो जाता है।

पुराने कोड में, एक अक्सर जाँच करता है कि नया ऑपरेटर वापस आ गया है। यह इस तरह दिखता है:

 int *p = new int[10]; if (!p) return false;

यदि स्मृति आबंटन विफल रहता है, तो C ++ भाषा मानक का समर्थन करने वाले आधुनिक कंपाइलरों को अपवाद छोड़ देना चाहिए ऐसा इसलिए किया जा सकता है कि 'नया' ऑपरेटर अपवादों को नहीं फेंकता है, लेकिन अब विचाराधीन मामलों से इसका कोई लेना-देना नहीं है।

इस प्रकार, अगर (पी) की जाँच करना अतिश्योक्तिपूर्ण है। सामान्य तौर पर, ऐसा कोड हानिरहित होता है। अतिरिक्त जांच। चिंता की कोई बात नहीं।
हालांकि, पुराने कोड से अप्रिय परिणाम हो सकते हैं। VirtualDub प्रोजेक्ट के एक टुकड़े पर विचार करें।

 void HexEditor::Find(HWND hwndParent) { .... int *next = new int[nFindLength+1]; char *searchbuffer = new char[65536]; char *revstring = new char[nFindLength]; .... if (!next || !searchbuffer || !revstring) { delete[] next; delete[] searchbuffer; delete[] revstring; return; } .... }

पीवी-स्टूडियो द्वारा जारी किया गया डायग्नोस्टिक संदेश: V668 'न्यू' के खिलाफ 'अगले' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि 'नए' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। VirtualDub hexviewer.cpp 2012

यदि स्ट्रिंग में एक अपवाद होता है "char * revstring = new char [nFindLength];", तो स्मृति रिसाव हो जाएगा। डिलीट [] स्टेटमेंट्स को नहीं बुलाया जाएगा। एक महत्वपूर्ण गलती नहीं है, लेकिन अभी भी इसके बारे में ध्यान देने योग्य है।

यहां , सभी स्थानों पर जहां वर्चुअलड्रब में 'नए' ऑपरेटर को कॉल करने के बाद पॉइंटर को सूचीबद्ध किया गया है।

नष्ट वस्तु से लिंक

 vdlist_iterator& operator--(int) { vdlist_iterator tmp(*this); mp = mp->mListNodePrev; return tmp; }

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक संदेश: वी 558 फ़ंक्शन अस्थायी स्थानीय ऑब्जेक्ट का संदर्भ देता है: tmp। VirtualDub vdstl.h 460

फ़ंक्शन को सही तरीके से लागू नहीं किया गया है। यह स्थानीय 'tmp' वस्तु का संदर्भ देता है। फ़ंक्शन से बाहर निकलने के बाद, यह पहले से ही नष्ट हो जाएगा। इस लिंक के साथ काम करने से अपरिभाषित व्यवहार होगा।

वैसे, पास में स्थित ++ ऑपरेटर को सही तरीके से लागू किया जाता है।

शुरुआत में हम उपयोग करते हैं, फिर हम जांच करते हैं

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

 LRESULT YUVCodec::DecompressGetFormat(BITMAPINFO *lpbiInput, BITMAPINFO *lpbiOutput) { BITMAPINFOHEADER *bmihInput = &lpbiInput->bmiHeader; BITMAPINFOHEADER *bmihOutput = &lpbiOutput->bmiHeader; LRESULT res; if (!lpbiOutput) return sizeof(BITMAPINFOHEADER); .... }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V595 'lpbiOutput' पॉइंटर को nullrr के खिलाफ सत्यापित करने से पहले उपयोग किया गया था। जाँच लाइनें: 82, 85. VirtualDub yuvcodec.cpp 82

शुरुआत में, lpbiOutput पॉइंटर को dereferenced किया जाता है। फिर यह जाँच की जाती है: "अगर (! LpbiOutput)"। ऐसी त्रुटियां आम तौर पर रिफैक्टरिंग के दौरान होती हैं। नया कोड आवश्यक जांच से पहले डाला जाता है। उपरोक्त कोड को ठीक करने के लिए, आपको क्रियाओं का क्रम बदलना होगा:

 LRESULT YUVCodec::DecompressGetFormat(BITMAPINFO *lpbiInput, BITMAPINFO *lpbiOutput) { if (!lpbiOutput) return sizeof(BITMAPINFOHEADER); BITMAPINFOHEADER *bmihInput = &lpbiInput->bmiHeader; BITMAPINFOHEADER *bmihOutput = &lpbiOutput->bmiHeader; LRESULT res; .... }

अन्य स्थान जहां विश्लेषक एक V595 चेतावनी जारी करता है, यहां सूचीबद्ध हैं ।

HRESULT प्रकार के साथ काम करें

 VDPosition AVIReadTunnelStream::TimeToPosition(VDTime timeInUs) { AVISTREAMINFO asi; if (AVIStreamInfo(pas, &asi, sizeof asi)) return 0; return VDRoundToInt64(timeInUs * (double)asi.dwRate / (double)asi.dwScale * (1.0 / 1000000.0)); }

PVS-Studio द्वारा जारी किया गया डायग्नोस्टिक संदेश: V545 HRFULT प्रकार के मान के लिए 'if' ऑपरेटर गलत है, तो AVIStreamInfoA (pas, और asi, sizeof asi)। इसके बजाय SUCCEEDED या FAILED मैक्रो का उपयोग किया जाना चाहिए। VirtualDub avireadhandlertunnelw32.cpp 230

AVIStreamInfo () फ़ंक्शन प्रकार HRESULT का मान लौटाता है। इस प्रकार की व्याख्या 'बूल' के रूप में नहीं की जा सकती है। HRESULT के एक चर में संग्रहीत जानकारी में एक जटिल संरचना है । HRESULT मान की जांच करने के लिए, आपको "WinError.h" में घोषित SUCCEEDED या FAILED मैक्रो का उपयोग करना होगा। यहाँ ये मैक्रोज़ कैसे काम करते हैं:

 #define FAILED(hr) (((HRESULT)(hr)) < 0) #define SUCCEEDED(hr) (((HRESULT)(hr)) >= 0)

सही कोड है:

 if (FAILED(AVIStreamInfo(pas, &asi, sizeof asi)))

PVS-Studio निम्नलिखित लाइनों को समान चेतावनी देता है:

avireadhandlertunnelw32.cpp 238
avireadhandlertunnelw32.cpp 335
inputfileavi.cpp 440
reference_d3d11.cpp 959

मैजिक नंबर

एक संख्या का उपयोग करके स्ट्रिंग की लंबाई निर्धारित करना एक अच्छा विचार नहीं है। पात्रों को गिनते समय गलतियाँ करना बहुत आसान है। एक उदाहरण:

 bool VDOpenGLBinding::Attach(....) { .... if (!memcmp(start, "GL_EXT_blend_subtract", 20)) .... }

पीवीएस-स्टूडियो द्वारा जारी किया गया डायग्नोस्टिक संदेश: V512 'मेमकैंप' फ़ंक्शन के कॉल से बफर '' GL_EXT_blend_subtract '' का प्रवाह समाप्त हो जाएगा। रिज़ा ओपेंगल। सीपी 393

स्ट्रिंग की लंबाई "GL_EXT_blend_subtract" 20 नहीं है, लेकिन 21 अक्षर हैं। त्रुटि अनियंत्रित है। व्यवहार में, कोई टकराव उत्पन्न नहीं होगा। हालांकि, इस तरह के जादू की संख्या से बचा जाना चाहिए। स्ट्रिंग की लंबाई को गिनने के लिए एक विशेष मैक्रो का उपयोग करना बेहतर है। एक उदाहरण:

 #define LiteralStrLen(S) (sizeof(S) / sizeof(S[0]) - 1)

C ++ में, आप एक अधिक सुरक्षित टेम्पलेट फंक्शन बना सकते हैं:

 template <typename T, size_t N> char (&ArraySizeHelper(T (&array)[N]))[N]; template <typename T, size_t N> size_t LiteralStrLen(T (&array)[N]) { return sizeof(ArraySizeHelper(array)) - 1; }

दूसरे विकल्प का लाभ यह है कि आप गलती से एक तर्क के रूप में एक साधारण पॉइंटर पास नहीं कर सकते हैं। यह तकनीक " पीवीएस-स्टूडियो बनाम क्रोमियम " लेख में अधिक विस्तार से वर्णित है।

पूर्ण पथ

 VDDbgHelpDynamicLoaderW32::VDDbgHelpDynamicLoaderW32() { hmodDbgHelp = LoadLibrary( "c:\\program files\\debugging tools for windows\\dbghelp"); if (!hmodDbgHelp) { hmodDbgHelp = LoadLibrary("c:\\program files (x86)\\...... .... }

PVS-Studio द्वारा जारी किया गया डायग्नोस्टिक संदेश: V631 'LoadLibraryA' फ़ंक्शन कॉल का निरीक्षण करने पर विचार करें। फ़ाइल या निर्देशिका के लिए एक निरपेक्ष पथ को परिभाषित करना एक खराब शैली माना जाता है। VirtualDub लीक। सीपीसी 67, 69

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

अमान्य तर्क

 sint64 rva; void tool_lookup(....) { .... printf("%08I64x %s + %x [%s:%d]\n", addr, sym->name, addr-sym->rva, fn, line); .... }

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक संदेश: V576 गलत प्रारूप। 'प्रिंटफ' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। तर्क 32-बिट से अधिक नहीं होने की उम्मीद है। असुका लुकअप। सीसी 56

चर 'rva' एक 64-बिट प्रकार है। इसका मतलब है कि 8 बाइट्स को स्टैक पर धकेल दिया जाएगा। Printf () फ़ंक्शन एक फ़ंक्शन होता है जिसमें विभिन्न प्रकार के तर्क होते हैं । प्रारूप स्ट्रिंग का उपयोग करके इसे जिस प्रकार का डेटा संसाधित करना चाहिए, वह निर्दिष्ट किया गया है। इस स्थिति में, चर 'rva' को 32-बिट चर ("% x") के रूप में संसाधित किया जाएगा।

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

हालाँकि, यदि परिवर्तनशील 'rva' INT_MAX से अधिक है, तो इसका मान वैसे भी सही ढंग से नहीं छापा जाएगा।

विश्लेषक यहां इसी तरह की चेतावनी देता है:

dubstatus.cpp 360
लुकआउट .pp 58

गलत तुलना

 void VDVideoCompressorVCM::GetState(vdfastvector<uint8>& data) { DWORD res; .... res = ICGetState(hic, data.data(), size); .... if (res < 0) throw MyICError("Video compression", res); }

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक संदेश: V547 एक्सप्रेशन 'रेस <0' हमेशा गलत होता है। अहस्ताक्षरित प्रकार का मान कभी नहीं है <0। Riza w32videocodecpack.cpp 828

चर 'रेस' में एक अहस्ताक्षरित DWORD प्रकार है। इसका मतलब यह है कि अभिव्यक्ति "रेस <0" हमेशा मूल्य 'झूठी' के बराबर होती है।

एक समान जाँच यहाँ है: w32videocodec.cpp 284।

एक और समान त्रुटि पर विचार करें।

 #define ICERR_CUSTOM -400L static const char *GetVCMErrorString(uint32 icErr) { .... if (icErr <= ICERR_CUSTOM) err = "A codec-specific error occurred."; .... }

PVS-Studio द्वारा जारी किया गया नैदानिक संदेश: V605 अभिव्यक्ति की पुष्टि करने पर विचार करें: icErr <= - 400L। एक अहस्ताक्षरित मूल्य संख्या -400 की तुलना में है। system error_win32.cpp 54

चर 'icErr' 'अहस्ताक्षरित' प्रकार का है। इसलिए, तुलना से पहले, '-400' संख्या को स्पष्ट रूप से 'अहस्ताक्षरित' में बदल दिया जाएगा। मान '-400' 4294966896 में बदल जाएगा। इस प्रकार, एक तुलना (icErr <= -400) (icErr <= 4294966896) के बराबर है। जाहिर है, यह वह नहीं है जो प्रोग्रामर चाहता था।

विविध विचित्र

 void AVIOutputFile::finalize() { .... if (stream.mChunkCount && hdr.dwScale && stream.mChunkCount) .... }

PVS-Studio द्वारा जारी किया गया डायग्नोस्टिक संदेश: V501 बाईं ओर और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ 'stream.mChunkCount' हैं। VirtualDub avioutputfile.cpp 761

चर 'stream.mChunkCount' को दो बार जांचा जाता है। एक जाँच अतिश्योक्तिपूर्ण है या कुछ और जाँच करना भूल गया है।

 void VDVideoCompressorVCM::Start(const void *inputFormat, uint32 inputFormatSize, const void *outputFormat, uint32 outputFormatSize, const VDFraction& frameRate, VDPosition frameCount) { this->hic = hic; .... }

PVS-Studio द्वारा जारी किया गया डायग्नोस्टिक संदेश: V570 'इस-> hic' वेरिएबल को ही असाइन किया गया है। रिजा w32videocodecpack.cpp 253

 void VDDialogAudioConversionW32::RecomputeBandwidth() { .... if (IsDlgButtonChecked(mhdlg, IDC_PRECISION_NOCHANGE)) { if (mbSourcePrecisionKnown && mbSource16Bit) bps *= 2; else bps = 0; } if (IsDlgButtonChecked(mhdlg, IDC_PRECISION_16BIT)) bps *= 2; .... }

पीवीएस-स्टूडियो द्वारा जारी किया गया नैदानिक संदेश: V646 आवेदन के तर्क का निरीक्षण करने पर विचार करें। यह संभव है कि 'और' कीवर्ड गायब है। VirtualDub optdlg.cpp 120

कोड ठीक से स्वरूपित नहीं किया जा सकता है। या शायद कीवर्ड 'और' भूल गया है।

 bool VDCaptureDriverScreen::Init(VDGUIHandle hParent) { .... mbAudioHardwarePresent = false; mbAudioHardwarePresent = true; .... }

PVS-Studio द्वारा जारी किया गया नैदानिक संदेश: V519 'mbAudioHardwarePresent' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। जाँच लाइनें: 274, 275. VDCapture cap_screen.cpp 275

निष्कर्ष

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

VirtualDub की जाँच करें