Your SlideShare is downloading. ×
Analysis of the Ultimate Toolbox project
Analysis of the Ultimate Toolbox project
Analysis of the Ultimate Toolbox project
Analysis of the Ultimate Toolbox project
Analysis of the Ultimate Toolbox project
Analysis of the Ultimate Toolbox project
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Analysis of the Ultimate Toolbox project

168

Published on

While testing the general analyzer included into PVS-Studio 4.00, we checked several open-source projects from the CodeProject site. One of those was Ultimate ToolBox.

While testing the general analyzer included into PVS-Studio 4.00, we checked several open-source projects from the CodeProject site. One of those was Ultimate ToolBox.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
168
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Analysis of the Ultimate Toolbox projectAuthor: Andrey KarpovDate: 23.12.2010While testing the general analyzer included into PVS-Studio 4.00, we checked several open-sourceprojects from the CodeProject site. One of those was Ultimate ToolBox.We found some errors in the code of the Ultimate Toolbox project and would like to describe themfurther in this article. For each case, we will give the diagnostic message generated by the analyzer,corresponding file and line number. We will also give the code fragment containing a particular errorand a brief error description. To study the samples thoroughly, you may visit the resources by the linksgiven in the text.1. Condition errorV501 There are identical sub-expressions to the left and to the right of the && operator. UTox3dtabview.cpp 230void COX3DTabViewContainer::OnNcPaint(){ ... if(rectClient.top<rectClient.bottom && rectClient.top<rectClient.bottom) { dc.ExcludeClipRect(rectClient); } ...}The V501 warning points to a condition error. It is most likely that there must be a condition comparingleft and right after the && operator.A similar error can also be found here:V501 There are identical sub-expressions to the left and to the right of the && operator. UToxtabclientwnd.cpp 1842. Condition which is always true.
  • 2. V547 Expression lpDrawItemStruct -> itemID >= 0 is always true. Unsigned type value is always >= 0. UToxautolistbox.cpp 56void COXAutoListBox::DrawItem(...){ ... if (lpDrawItemStruct->itemID>=0) { ... } ...}The "lpDrawItemStruct->itemID>=0" condition always holds because the itemID member has the UINTtype. Such errors are described in detail in documentation (V547). The code must have looked this way:if (lpDrawItemStruct->itemID != (UINT)(-1)){ ...}3. Condition which is always false.V547 Expression lpms -> itemID < 0 is always false. Unsigned type value is never < 0. UToxcoolcombobox.cpp 476void COXCoolComboBox::MeasureItem(...){ if(lpms->itemID<0) lpms->itemHeight=m_nDefaultFontHeight+1; else lpms->itemHeight= m_nDefaultFontHeightSansLeading+1;}
  • 3. The V547 warning tells us that the code "lpms->itemHeight=m_nDefaultFontHeight+1;" will be alwaysexecuted. Like in the previous case, it is caused by the fact that the itemID member has the unsignedtype UINT.4. Inefficient codeV801 Decreased performance. It is better to redefine the first function argument as a reference.Consider replacing const .. mi with const .. &mi. UT oxdllmanager.h 123BOOL operator==(const _tagMODULEINFO mi) const{ return ((hModule==mi.hModule)& (sModuleFileName.CompareNoCase(mi.sModuleFileName)==0));}This code does not contain an error, but we may make it more efficient. There is no need in creating acopy of the _tagMODULEINFO structure each time the == operator is called. The V801 message tells usthat we may replace "const _tagMODULEINFO mi" with "const _tagMODULEINFO &mi".5. Condition errorV501 There are identical sub-expressions to the left and to the right of the == operator: dwDockStyle== dwDockStyle UT oxframewnddock.cpp 190void COXFrameWndSizeDock::TileDockedBars( DWORD dwDockStyle){ ... if (pDock != NULL && (pDock->m_dwStyle && dwDockStyle == dwDockStyle)) ...}It is most likely that the programmer intended to write some other expression instead of the"dwDockStyle == dwDockStyle" expression.6. Handling char as unsigned char
  • 4. Two warnings at once were given for one line:V547 Expression chNewChar >= 128 is always false. The value range of signed char type: [-128, 127].UT oxmaskededit.cpp 81V547 Expression chNewChar <= 255 is always true. The value range of signed char type: [-128, 127]. UToxmaskededit.cpp 81BOOL CMaskData::IsValidInput(TCHAR chNewChar){ ... if((chNewChar >= 128) && (chNewChar <= 255)) bIsValidInput=TRUE ; ...}This condition is meaningless since the chNewChar variables value range is [-128..127]. It means thatthe condition will never hold.7. Logic errorV517 The use of if (A) {...} else if (A) {...} pattern was detected. There is a probability of logical errorpresence. UT oxprocess.h 583inline COXProcessIterator& operator+(int nOffset){ if(nOffset>0) Next(nOffset); else if(nOffset>0) Prev(-nOffset); return *this;}The V517 warning points to an error in programs logic. The "Prev(-nOffset);" branch will never beexecuted. The correct code must look as follows:inline COXProcessIterator& operator+(int nOffset){ if(nOffset>0)
  • 5. Next(nOffset); else if(nOffset<0) Prev(-nOffset); return *this;}There are similar errors in other programs fragments:V517 The use of if (A) {...} else if (A) {...} pattern was detected. There is a probability of logical errorpresence. UT oxprocess.h 596V517 The use of if (A) {...} else if (A) {...} pattern was detected. There is a probability of logical errorpresence. UT oxprocess.h 610V517 The use of if (A) {...} else if (A) {...} pattern was detected. There is a probability of logical errorpresence. UT oxprocess.h 6248. Condition which is always false.V547 Expression m_nCurrentIndex - nOffset < 0 is always false. Unsigned type value is never < 0. UToxprocess.cpp 594int m_nCurrentIndex;...BOOL COXProcessIterator::Prev(UINT nOffset){ ... if(m_nCurrentIndex-nOffset<0) return FALSE; ...}Since the "m_nCurrentIndex-nOffset" expression has the unsigned type, it will never be below 0.9. Error ASSERT()V501 There are identical sub-expressions to the left and to the right of the && operator. UToxscrollwnd.cpp 645void COXScrollWnd::OnPrepareDC(...)
  • 6. { ... ASSERT(m_totalDev.cx>=0 && m_totalDev.cx>=0); ...}There must be this code:ASSERT(m_totalDev.cx>=0 && m_totalDev.cy>=0);There is also a similar error here:V501 There are identical sub-expressions to the left and to the right of the && operator. UToxzoomvw.cpp 179

×