🙇🏻 👎 💷 विंडोज के लिए इंटेल आईपीपी नमूने

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

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

सभी उदाहरणों को चार समूहों में बांटा गया है:

विंडोज के लिए आईपीपी नमूने
विंडोज के लिए आईपीपी यूआईसी डेमो
विंडोज के लिए आईपीपी डीएमआईपी नमूने
विंडोज के लिए आईपीपी क्रिप्टोग्राफी के नमूने

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

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

मैं इस बात पर जोर देता हूं कि विंडोज के लिए आईपीपी नमूने एक उच्च गुणवत्ता वाली परियोजना है। हालांकि, इसके 1.6 मिलियन लाइनों के आकार के कारण, इसमें अनिवार्य रूप से कई प्रकार की त्रुटियां हैं। आइए उनमें से कुछ पर विचार करें।

सरणी सूचकांकों को बदलने में विफल

यह उदाहरण उल्लेखनीय रूप से मेरे पिछले लेख " कॉपी-पेस्ट तकनीक का उपयोग करने का परिणाम जब C ++ में प्रोग्रामिंग कर रहा है और इससे कैसे निपटना है ":

  संरचना AVS_MB_INFO
 {
   ...
   Ipp8u refIdx [AVS_DIRECTIONS] [4];
   ...
 };

 शून्य AVSCompressor :: GetRefInduritiesBSlice (void) {
   ...
   अगर (m_pMbInfo-> predType [0] और predType)
   {
     m_refIdx [iRefNum] = m_pMbInfo-> refIdx [dir] [0];
     iRefNum + = 1;
   }
   अगर (m_pMbInfo-> predType [1] और predType)
   {
     m_refIdx [iRefNum] = m_pMbInfo-> refIdx [dir] [1];
     iRefNum + = 1;
   }
   अगर (m_pMbInfo-> predType [2] और predType)
   {
     m_refIdx [iRefNum] = m_pMbInfo-> refIdx [dir] [2];
     iRefNum + = 1;
   }
   अगर (m_pMbInfo-> predType [3] और predType)
   {
     m_refIdx [iRefNum] = m_pMbInfo-> refIdx [dir] [30];
     iRefNum + = 1;
   }
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: वी 557 ऐरे ओवररन संभव है। '30' इंडेक्स सरणी बाउंड से परे इंगित कर रहा है। avs_enc umc_avs_enc_compressor_enc_b.cpp 495

प्रोग्रामर ने कोड के टुकड़े को कई बार कॉपी किया और सरणी सूचकांकों के मूल्य को बदल दिया। लेकिन अंत में उसका हाथ कांप गया। उसने नंबर 3 में प्रवेश किया, लेकिन नंबर 0 को नहीं हटाया। नतीजतन, सूचकांक 30 प्राप्त किया गया था, और जब कोड निष्पादित किया जाता है, तो पहुंच सरणी की सीमाओं से बहुत आगे निकल जाएगी।

समान कोड शाखाएँ

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

  AACStatus anacencGetFrame (...)
 {
   ...
   अगर (अधिकतम [0]> अधिकतम [1]) {
     ics [1] .num_window_groups = ics [0] .num_window_groups;
     for (g = 0; g <ics [0] .num_window_groups; g ++) {
       ics [1] .len_window_group [g] = ics [0] .len_window_group [जी];
     }
   } {
     ics [1] .num_window_groups = ics [0] .num_window_groups;
     for (g = 0; g <ics [0] .num_window_groups; g ++) {
       ics [1] .len_window_group [g] = ics [0] .len_window_group [जी];
     }
   }
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V523 'तब' कथन 'और' कथन के बराबर है। aac_enc anac_enc_api_fp.c 1379

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

डिक्रिप्शन ऑपरेशन प्राथमिकता के साथ भ्रम "-" और डीफ्रेन्सिंग पॉइंटर "*"

  स्थिर शून्य
 sbrencConflictResolution (..., Ipp32s * nLeftBord)
 {
   ...
   * nLeftBord = nBordNext - 1;
   ...
   अगर (* lenBordNext> 1) {
     ...
     * nLeftBord--;
   }
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V532 '* पॉइंटर--' पैटर्न के कथन का निरीक्षण करने पर विचार करें। शायद इसका मतलब है: '(* सूचक) -'। aac_enc sbr_enc_frame_gen.c 428

NLeftBord पॉइंटर का उपयोग sbrencConflictResolution फ़ंक्शन से मान वापस करने के लिए किया जाता है। सबसे पहले, मूल्य "nBordNext - 1" को निर्दिष्ट पते पर लिखा जाता है। कुछ शर्तों के तहत, इस मूल्य में एक की कमी होनी चाहिए। मान को कम करने के लिए, प्रोग्रामर ने निम्नलिखित कोड का उपयोग किया:

  * nLeftBord--;

त्रुटि यह है कि मूल्य के बजाय, सूचक स्वयं कम हो जाता है। सही कोड इस तरह दिखना चाहिए:

  (* nLeftBord) -;

वेतन वृद्धि ऑपरेटर "++" और डीफ्रेंसिंग पॉइंटर "*" के साथ एक और भी भ्रामक स्थिति

निम्नलिखित कोड मेरे लिए पूरी तरह से समझ से बाहर है। मुझे नहीं पता कि इसे कैसे ठीक करना है ताकि यह समझ में आए। शायद यहाँ कुछ याद आ रहा है।

  स्थिर IppStatus mp2_HuffmanTableInitAlloc (Ipp32s * tbl, ...)
 {
   ...
   के लिए (i = 0; मैं <num_tbl; i ++) {
     * tbl ++;
   }
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V532 '* पॉइंटर ++' पैटर्न के कथन का निरीक्षण करने पर विचार करें। शायद इसका मतलब है: '(* सूचक) ++'। mpeg2_dec umc_mpeg2_dec.cpp 59

अब, उदाहरण में दिखाया गया लूप निम्न कोड के बराबर है:

  tbl + = num_tbl;

पीवीएस-स्टूडियो विश्लेषक ने सुझाव दिया कि शायद कोष्ठक यहां भूल गए हैं और आपको "(* tbl) ++" लिखना चाहिए। लेकिन इस कोड का कोई मतलब नहीं है। फिर लूप बराबर होगा:

  * tbl + = num_tbl;

सामान्य तौर पर, एक बहुत ही अजीब तरह का चक्र। एक त्रुटि है, लेकिन स्पष्ट रूप से केवल कोड के लेखक ही इसे ठीक कर सकते हैं।

एक त्रुटि हुई है कि संकेत का नुकसान

कोड में एक फ़ंक्शन "GetTrackByPidOrCreateNew" है, जो यदि कोई त्रुटि होती है, तो "-1" मान लौटाता है।

  typedef ने int Ipp32s पर हस्ताक्षर किए;
 typedef अहस्ताक्षरित int Ipp32u;

 Ipp32s StreamParser :: GetTrackByPidOrCreateNew (Ipp32s iPid, bool * pIsNew)
 {
   ...
   और अगर (pIsNew || m_uiTracks> = MAX_TRACK)
     वापसी -1;
   ...
 }

"GetTrackByPidOrCreateNew" फ़ंक्शन के साथ सब कुछ ठीक है। लेकिन इसका उपयोग करते समय एक त्रुटि है:

  स्थिति स्ट्रीमरसर :: GetNextData (MediaData * pData, Ipp32u * pTrack)
 {
   ...
   * pTrack = GetTrackByPidOrCreateNew (m_pPacket-> iPid, NULL);

   अगर (* pTrack> = 0 && TRACK_LPCM == m_pInfo [* pTrack] -> m_Type)
     ippsSwapBytes_16u_I ((Ipp16u *) pData-> GetDataPointer (),
                         m_pPacket-> uiSize / 2);
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V547 एक्सप्रेशन '* pTrack> = 0' हमेशा सच होता है। अहस्ताक्षरित प्रकार का मान हमेशा> = 0. डिम्यूसर umc_stream_parser.cpp 179 है

मान जो GetTrackByPidOrCreateNew फ़ंक्शन देता है, वह अहस्ताक्षरित प्रारूप (अहस्ताक्षरित int) में संग्रहीत होता है। इसका मतलब यह है कि "-1" "4294967295" में बदल जाएगा, और हालत "* pTrack> = 0" हमेशा सच है।

परिणामस्वरूप, यदि फ़ंक्शन "GetTrackByPidOrCreateNew" मान "-1" लौटाता है, तो एक्सेस उल्लंघन तब होगा जब कोड "m_pInfo [* pTrack] -> m_Type निष्पादित किया जाता है।

कॉपी-पेस्ट और भूल गए +1

  शून्य H264SegmentDecoder :: ResetDeblockingVariablesMBAFF ()
 {
   ...
   अगर (GetMBFieldDecodingFlag (m_gmbinfo-> mbs [m_CurMBAadr) 
                                             - mb_width * 2]))
     m_deblockingParams.nNeighbor [HORIZONTAL_DEBLOCKING] =
       m_CurMBAddr - mb_width * 2;
   अन्यथा
     m_deblockingParams.nNeighbor [HORIZONTAL_DEBLOCKING] =
       m_CurMBAddr - mb_width * 2;
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V523 'तब' कथन 'और' कथन के बराबर है। h264_dec umc_h264_segment_decoder_deblocking_mbaff.cpp 340

यदि आप पास के कोड को देखते हैं, तो यह स्पष्ट हो जाता है कि वे प्रतिलिपि की गई पंक्ति में एक जोड़ना भूल गए थे। सही कोड इस तरह दिखना चाहिए:

  अगर (GetMBFieldDecodingFlag (m_gmbinfo-> mbs [m_CurMBAadr) 
                                           - mb_width * 2]))
   m_deblockingParams.nNeighbor [HORIZONTAL_DEBLOCKING] =
     m_CurMBAddr - mb_width * 2;
 अन्यथा
   m_deblockingParams.nNeighbor [HORIZONTAL_DEBLOCKING] =
     m_CurMBAddr - mb_width * 2 + 1;

"H264CoreEncoder_ResetDeblockingVariablesMBAFF" फ़ंक्शन में पास में भूल गए "+ 1" के साथ अभी भी वही त्रुटि है।

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V523 'तब' कथन 'और' कथन के बराबर है। h264_enc umc_h264_deblocking_mbaff_tmpl.cpp.h 366

निकालें, जो कुछ भी नहीं निकालता है।

  void H264ThreadGroup :: RemoveThread (H264Thread * थ्रेड)
 {
     AutomaticUMCMutex गार्ड (m_mGuard);
     std :: remove (m_threads.begin (), m_threads.end (), thread);
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V530 फ़ंक्शन 'वापसी' के रिटर्न मूल्य का उपयोग करने की आवश्यकता है। h264_dec umc_h264_thread.cpp 226

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

  m_threads .erase (
   std :: remove (m_threads.begin (), m_threads.end (), thread),
   m_threads.end ());

स्वयं के साथ संरचना क्षेत्रों की तुलना

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

  बूल H264_AU_Stream :: IsPictureSame (H264SliceHeaderParse & p_newHeader)
 {
   अगर ((p_newHeader.frame_num! = m_lastSlice.frame_num) ||
       (p_newHeader.pic_parameter_set_id! =
        p_newHeader.pic_parameter_set_id) ||
       (p_newHeader.field_pic_flag! = p_newHeader.field_pic_flag) ||
       (p_newHeader.bottom_field_flag! = m_lastSlice.bottom_field_flag)
       ) {
       झूठे लौटना;
   }
   ...
 }

पीवीएस-स्टूडियो नैदानिक संदेश:

V501 समान उप-अभिव्यक्तियाँ हैं 'p_newHeader.pic_parameter_set_id' बाईं ओर और '=!' संचालक के दाईं ओर। h264_spl umc_h264_au_stream.cpp 478

V501 समान उप-अभिव्यक्तियाँ हैं 'p_newHeader.field_pic_flag' बाईं ओर और '! =' संचालक के दाईं ओर। h264_spl umc_h264_au_stream.cpp 479

तुलना फ़ंक्शन काम नहीं करता है, क्योंकि संरचना के कुछ सदस्यों की तुलना स्वयं के साथ की जाती है। यहाँ दो सही लाइनें हैं:

  (p_newHeader.pic_parameter_set_id! = m_lastSlice.pic_parameter_set_id)
 ||
 (p_newHeader.field_pic_flag! = m_lastSlice.field_pic_flag) ||

गलत डेटा कॉपी

गलत वस्तुओं का उपयोग करने में त्रुटियां हैं, न केवल तुलना करते समय, बल्कि वस्तुओं की स्थिति की नकल करते समय भी:

  Ipp32s ippVideoEncoderMPEG4 :: Init (mp4_Param * बराबर)
 {
   ...
   VOL.sprite_width = par-> sprite_width;
   VOL.sprite_height = par-> sprite_height;
   VOL.sprite_left_coordinate = par-> sprite_left_coordinate;
   VOL.sprite_top_coordinate = par-> sprite_left_coordinate;
   ...
 }

PVS- स्टूडियो डायग्नोस्टिक संदेश: V537 'sprite_left_coordinate' आइटम के उपयोग की शुद्धता की समीक्षा करने पर विचार करें। mpeg4_enc mp4_enc_misc.cpp 387

अमान्य मान VOL.sprite_top_coordinate में रखा गया है। सही असाइनमेंट इस तरह दिखना चाहिए:

  VOL.sprite_top_coordinate = par-> sprite_top_coordinate;

एक चर पर दो छोरों

  JERRCODE CJPEGDecoder :: DecodeScanBaselineNI (शून्य)
 {
   ...
   के लिए (c = 0; c <m_scan_ncomps; c ++)
   {
     ब्लॉक = m_block_buffer + (DCTSIZE2 * m_nblock * (j + (i * m_numxMCU)));

     // किसी भी प्रासंगिक घटकों को छोड़ें
     for (c = 0; c <m_ccomp [m_curr_comp_no] .m_comp_no; c c)
     {
       ब्लॉक + = (DCTSIZE2 * m_ccomp [c] .m_nblocks);
     }
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V535 चर 'c' का उपयोग इस लूप के लिए और बाहरी लूप के लिए किया जा रहा है। jpegcodec jpegdec.cpp 4652

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

अधिक विश्वसनीयता के लिए डबल असाइनमेंट

  H264EncoderFrameType *
 H264ENC_MAKE_NAME (H264EncoderFrameList_findOldestToEncode) (...)
 {
   ...
   MaxBrefPOC = 
     H264ENC_MAKE_NAME (H264EncoderFrame_PicOrderCnt) (pCurr, 0, 3);
   MaxBrefPOC = 
     H264ENC_MAKE_NAME (H264EncoderFrame_PicOrderCnt) (pCurr, 0, 3);
   ...
 }

PVS-Studio नैदानिक संदेश: V519 'MaxBrefPOC' ऑब्जेक्ट को दो बार क्रमिक रूप से असाइन किया गया है। शायद यह एक गलती है। h264_enc umc_h264_enc_cpb_tmpl.cpp.h 784

जब मैंने इस कोड को देखा, तो मुझे पुरानी प्रोग्रामिंग मजाक याद आई:

- और आपके पास अपने कोड में एक पंक्ति में दो समान GOTO क्यों हैं?

- अगर पहला काम न करे तो क्या होगा!

यह त्रुटि शायद महत्वपूर्ण नहीं है, लेकिन फिर भी यह एक गलती है।

कोड है कि खतरनाक है

  AACStatus sbrencResampler_v2_32f (Ipp32f * pSrc, Ipp32f * pDst)
 {
   ...
   k = nCoef-1;
   k = nCoef;
   ...
 }

PVS- स्टूडियो डायग्नोस्टिक संदेश: V519 'k' ऑब्जेक्ट को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। anac_enc sbr_enc_resampler_fp.c 90

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

न्यूनतम मूल्य जो पूरी तरह से न्यूनतम नहीं है

  शून्य MeBase :: MakeVlcTableDecision ()
 {
   ...
   Ipp32s BestMV = IPP_MIN (IPP_MIN (m_cur.MvRate [0], m_cur.MvRate [1]))
                          IPP_MIN (m_cur.MvRate [2], m_cur.MvRate [3]));
   Ipp32s BestAC = IPP_MIN (IPP_MIN (m_cur.AcRate [0], m_cur.AcRate [1]),
                          IPP_MIN (m_cur.AcRate [2], m_cur.AcRate [2]));
   ...
 }

PVS-Studio डायग्नोस्टिक संदेश: V501 बाईं और '<' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ हैं: (m_cur.AcRate [2]) <(m_cur.AcRate [2]) me umc_me.cpp 898

फिर से एरे इंडेक्स में टाइपो। अंतिम इंडेक्स 3 होना चाहिए, न कि 2. कोड का सही संस्करण:

  Ipp32s BestAC = IPP_MIN (IPP_MIN (m_cur.AcRate [0], m_cur.AcRate [1]),
                        IPP_MIN (m_cur.AcRate [2], m_cur.AcRate [3]);

ऐसी त्रुटियां अप्रिय हैं कि कोड "लगभग काम करता है।" त्रुटि तभी प्रकट होगी जब न्यूनतम तत्व "m_cur.AcRate [3]" में संग्रहीत हो। इस तरह की त्रुटियां परीक्षण के दौरान खुद को साबित करना पसंद करती हैं, लेकिन उपयोगकर्ता को उनके इनपुट डेटा सेट पर।

अधिकतम मूल्य, जो काफी अधिकतम नहीं है

अधिकतम मूल्यों के साथ, यह हमेशा अच्छा नहीं होता है:

  Ipp32s ippVideoEncoderMPEG4 :: Init (mp4_Param * बराबर)
 {
   ...
   i = IPP_MAX (mBVOPsearchHorBack, mBVOPsearchHorBack);
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V501 समान उप-अभिव्यक्तियाँ हैं (mBVOPsearchHorBack) 'बाईं ओर और'> 'ऑपरेटर के दाईं ओर। mpeg4_enc mp4_enc_misc.cpp 547

MBVOPsearchHorBack चर का उपयोग दो बार किया जाता है। यह वास्तव में mBVOPsearchHorBack और mBVOPsearchVerBack का उपयोग करने की योजना बनाई गई थी:

  i = IPP_MAX (mBVOPsearchHorBack, mBVOPsearchVerBack);

हमने आकाश को उंगली से मारा

  टाइप्डिफ़ संरचना
 {
   ...
   VM_ALIGN16_DECL (Ipp32f) nb_short [2] [3] [__ ALIGNED (MAX_PPT_SHORT)];
   ...
 } mpaPsychoacousticBlock;

 स्थिर शून्य mp3encPsy_short_window (...)
 {
   ...
   अगर (win_counter == 0) {
     nb_s = pBlock-> nb_short [0] [3];
   }
   ...
 }

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: वी 557 ऐरे ओवररन संभव है। '3' सूचकांक सरणी बाउंड से परे इंगित कर रहा है। mp3_enc mp3enc_psychoacoustic_fp.c 726

जाहिरा तौर पर एक सरल टाइपो है। गलती से '2' के बजाय इंडेक्स '3' का इस्तेमाल किया। मुझे लगता है कि परिणाम, समझने योग्य हैं।

काम की गति को धीमा करने में त्रुटि

  शून्य lNormalizeVector_32f_P3IM (Ipp32f * vec [3], Ipp32f * मास्क, 
                                Ippps लेन) {
   Ipp32s i;
   Ipppf मानदंड;

   के लिए (i = 0; मैं <लेन; मैं ++) {
     अगर (मुखौटा <0) जारी है;
     norm = 1.0f / sqrt (vec [0] [i] * vec [0] [i] +
            vec [१] [i] * vec [१] [i] +
            vec [2] [i] * vec [२] [i]);
            vec [0] [i] * = मानदंड;  vec [1] [i] * = मानदंड;  vec [2] [i] * = मानदंड;
   }
 }

PVS- स्टूडियो नैदानिक संदेश: V503 यह एक निरर्थक तुलना है: सूचक <0। ipprsample ippr_sample.cpp 501

यह कोड का एक सुंदर उदाहरण है, जो एक त्रुटि के कारण, धीरे-धीरे अधिक काम करता है। एल्गोरिथ्म को केवल उन तत्वों को सामान्य करना चाहिए जो मुखौटा सरणी में चिह्नित हैं। लेकिन उपरोक्त कोड सभी तत्वों का सामान्यीकरण करता है। त्रुटि स्थिति में है "अगर (मुखौटा <0)"। यहां वे "i" इंडेक्स का उपयोग करना भूल गए। मास्क पॉइंटर लगभग हमेशा शून्य से अधिक या बराबर होगा, जिसका अर्थ है कि हम सभी तत्वों को संसाधित करेंगे।

सही जांच:

  अगर (मुखौटा [i] <0) जारी है;

घटाव का परिणाम हमेशा 0 होता है

  int ec_fb_GetSubbandNum (शून्य * स्टेट)
 {
     _fbECState * state = (_ fbECState *) स्टेट;
     वापसी (राज्य-> फ्रीक-स्टेट-> फ्रीक);
 }

PVS-Studio डायग्नोस्टिक संदेश: V501 बाईं और 'दाईं ओर' के समान उप-अभिव्यक्तियाँ हैं - 'ऑपरेटर': राज्य-> freq - राज्य-> freq वाक ec_fb.c 250

यहां, एक टाइपो के कारण, फ़ंक्शन हमेशा मान वापस कर देगा 0. कुछ गलत है, हम यहां घटाते हैं। आपको क्या घटाना है, मुझे नहीं पता।

बफर की कमी की गलत हैंडलिंग

  typedef अहस्ताक्षरित int Ipp32u;

 UMC :: स्थिति Init (..., Ipp32u याद रखें, ...)
 {
   ...
   memSize - = UMC :: align_value <Ipp32u> (m_nFrames * sizeof (फ्रेम));
   अगर (याद रखें <0)
       वापसी UMC :: UMC_ERR_NOT_ENOUGH_BUFFER;
   ...
 }

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

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

यह शायद किसी कार्यक्रम की हमला करने की भेद्यता का एक अच्छा उदाहरण है। गलत डेटा खिसकने से आप बफर को ओवरफ्लो कर सकते हैं और उसका उपयोग करने का प्रयास कर सकते हैं। वैसे, लगभग 10 ऐसी कमजोरियां थीं। मैं उन्हें पाठ को अव्यवस्थित नहीं करने के लिए नहीं लाऊंगा।

गलत चेक और, परिणामस्वरूप, सरणी की सीमा से बाहर जाना

  Ipp32u m_iCurrMBIndex;
 VC1EncoderMBInfo * VC1EncoderMBs :: GetPevMBInfo (Ipp32s x, Ipp32s y)
 {
   Ipp32s पंक्ति = (y> 0)?  m_iPrevRowIndex: m_iCurrRowIndex;
   वापसी ((m_iCurrMBIndex - x <0 || row <0)? 0?)
     & m_MBInfo [पंक्ति] [m_iCurrMBIndex - x]);
 }

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

चर "m_iCurrMBIndex" प्रकार का "अहस्ताक्षरित" है। इस वजह से, अभिव्यक्ति "m_iCurrMBIndex - x" भी "अहस्ताक्षरित" प्रकार का है। इसलिए, स्थिति "m_iCurrMBIndex - x <0" हमेशा झूठी होती है। परिणामों पर विचार करें।

चलो चर "m_iCurrMBIndex" 5 है, और चर "x" 10 है।

अभिव्यक्ति "m_iCurrMBIndex - x" 5u - 10i = 0xFFFFFFFBu है।

"M_iCurrMBIndex - x <0" स्थिति झूठी है।

अभिव्यक्ति "m_MBInfo [पंक्ति] [0xFFFFFFFBu]" निष्पादित की गई है और सरणी पार हो गई है।

टर्नेरी संचालक का उपयोग करने में त्रुटि '?:'।

टर्नरी ऑपरेटर काफी खतरनाक है, क्योंकि गलती करना आसान है। हालांकि, प्रोग्रामर को कम लिखना और एक दिलचस्प भाषा निर्माण का उपयोग करना पसंद है। C ++ भाषा इसे सजा देती है।

  vm_file * vm_file_fopen (...)
 {
   ...
   mds [3] = FILE_ATTRIBUTE_NORMAL |
            (islog == 0)?  0: FILE_FLAG_NO_BUFFERING;
   ...
 }

PVS- स्टूडियो डायग्नोस्टिक संदेश: V502 शायद '?' 'ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' की तुलना में ऑपरेटर की प्राथमिकता कम है। ऑपरेटर। vm vm_file_win.c 393

कोड FILE_ATTRIBUTE_NORMAL और FILE_FLAG_NO_BUFFERING झंडे का संयोजन होना चाहिए। लेकिन वास्तव में, "mds [3]" तत्व को हमेशा मान 0 दिया जाता है।

प्रोग्रामर भूल गया कि ऑपरेटर | "?:" ऑपरेटर की प्राथमिकता से अधिक है। यह पता चला है कि निम्नलिखित अभिव्यक्ति कोड में लिखी गई है (कोष्ठक पर ध्यान दें):

(FILE_ATTRIBUTE_NORMAL | (islog == 0))?

0: FILE_FLAG_NO_BUFFERING;

शर्त FILE_ATTRIBUTE_NORMAL | (.log == 0) "हमेशा सत्य होता है और हम तत्व" mds [3] "को 0 पर सेट करते हैं।

सही अभिव्यक्ति इस तरह दिखनी चाहिए (फिर से, कोष्ठक पर ध्यान दें):

  FILE_ATTRIBUTE_NORMAL |
   ((islog == 0))?  0: FILE_FLAG_NO_BUFFERING);

एक सरणी के साथ अजीब काम

  AACStatus alsdecGetFrame (...)
 {
   ...
   के लिए (i = 0; मैं <num; मैं ++) {
     ...
     * tmpPtr = (Ipp32s) ((tmp << 24) + ((tmp & 0xff00) << t)
                       ((tmp >> 8) & 0xff00) + (tmp >> 24));
     * tmpPtr = * srcPrt;
     ...
   }
   ...
 }

PVS- स्टूडियो डायग्नोस्टिक संदेश: V519 '* tmpPtr' ऑब्जेक्ट को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। aac_dec als_dec_api.c 928

मैं पाठक को कोड का अध्ययन करने और निष्कर्ष निकालने का सुझाव देता हूं। मैं इस कोड का वर्णन सिर्फ एक शब्द में करूंगा - "मूल"।

पैरानॉर्मल असाइनमेंट्स

  स्थिर
 IPLStatus ownRemap8u_Pixel (...) {
   ...
   saveXMask = xMap-> मास्करी;
   saveXMask = NULL;
   saveYMask = yMap-> मास्करी;
   saveYMask = NULL;  
   ...
 }

पीवीएस-स्टूडियो नैदानिक संदेश:

V519 'saveXMask' ऑब्जेक्ट को क्रमिक रूप से दो बार मान असाइन किया गया है। शायद यह एक गलती है। ipl iplremap.c 36

V519 'saveYMask' ऑब्जेक्ट को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। ipl iplremap.c 38

इस तरह के एक अजीब कोड की उपस्थिति का कारण मेरे लिए स्पष्ट नहीं है। इसके अलावा, एक समान ब्लॉक 8 कार्यों में दोहराया जाता है!

एक चर के अन्य संदिग्ध कार्य हैं:

  Ipp32s ippVideoEncoderMPEG4 :: Init (mp4_Param * बराबर)
 {
   ...
   mNumOfFrames = par-> NumOfFrames;
   mNumOfFrames = -1;
   ...
 }

PVS- स्टूडियो डायग्नोस्टिक संदेश: V519 'mNumOfFrames' ऑब्जेक्ट को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। mpeg4_enc mp4_enc_misc.cpp 276

निष्कर्ष

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

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

आपके C / C ++ / C ++ 0x प्रोजेक्ट्स में सभी को शुभकामनाएँ। और मैं चाहता हूं कि मेरे द्वारा स्थैतिक विश्लेषण पद्धति का उपयोग करते हुए और अधिक त्रुटियां मिलें।

विंडोज के लिए इंटेल आईपीपी नमूने - त्रुटि से निपटने