The author analyzes the WinMerge project with the latest version of the PVS-Studio static code analyzer, finding several new errors compared to a previous analysis. Regular re-analysis is important as analyzers improve over time and new defects arise. Various logic errors are presented, such as unsigned integer comparisons that are always true, null pointer dereferences, and incorrect function argument types. The analyzer's ability to find new types of errors shows it continues advancing in correctly identifying defects.

1. Checking WinMerge with PVS-Studio for
the second time
Author: Andrey Karpov
Date: 28.03.2012
The article continues the idea that static code analyzers are tools to be used regularly, not once.
Introduction
The PVS-Studio analyzer allows you to detect errors in C/C++ applications. We checked the WinMerge
with it some time ago. There were few errors whose description can be found in the article "Comparing
the general static analysis in Visual Studio 2010 and PVS-Studio by examples of errors detected in five
open source projects" [1].
A year has passed since then, and we have decided to test the new version of WinMerge with the new
version of PVS-Studio. Below are the results of this second check. But what is the most important, there
is the following conclusion to draw from it:
There is no sense in checking a project with a static code analysis tool only once and get satisfied with
it. Analysis should be performed regularly.
These are the reasons:
1) Every new analyzer's version usually contains new diagnostic rules, which means that you can
detect more errors.
2) New errors appear in the program while writing new code. The cheapest way to detect many of
them is to use static code analyzers [2].
Let's get back to the defects found in the code. Note that many of the errors described here refer not to
the WinMerge project itself but the libraries it uses. However, it doesn't matter. We just wanted to
show that the PVS-Studio analyzer is quickly developing and learning to detect more new types of bugs.
The examples below prove it.
Fragments of odd code
Fragment N1
BOOL CCrystalEditView::
DoDropText (....)
{
...

2. UINT cbData = (UINT) ::GlobalSize (hData);
UINT cchText = cbData / sizeof(TCHAR) - 1;
if (cchText < 0)
return FALSE;
...
}
PVS-Studio's diagnostic rule: V547 Expression 'cchText < 0' is always false. Unsigned type value is never <
0. Merge ccrystaleditview.cpp 1135
The GlobalSize() function returns value 0 in case of an error. If it happens, this case will be handled
incorrectly. The code is built using unsigned data types, the 'cchText' variable also being of the
'unsigned' type. It means that the "cchText < 0" condition is always false. The code can be fixed by
rewriting it in the following way:
UINT cbData = (UINT) ::GlobalSize (hData);
if (cbData < sizeof(TCHAR))
return FALSE;
UINT cchText = cbData / sizeof(TCHAR) - 1;
Fragment N2
bool isopenbrace (TCHAR c)
{
return c == _T ('{') || c == _T ('(') ||
c == _T ('[') || c == _T ('<');
}
bool isclosebrace (TCHAR c)
{
return c == _T ('}') || c == _T ('}') ||
c == _T (']') || c == _T ('>');
}
PVS-Studio's diagnostic rule: V501 There are identical sub-expressions to the left and to the right of the
'||' operator: c == L'}' || c == L'}' Merge ccrystaleditview.cpp 1556

3. In the isclosebrace() function, the 'c' variable is compared to the '}' character twice. If you examine the
isopenbrace() function's code, you'll understand that the 'c' variable should be compared with the ')'
character in the second case.
Fragment N3
static HRESULT safeInvokeA(....)
{
HRESULT h;
...
// set h to FAILED
h = -1;
...
}
PVS-Studio's diagnostic rule: V543 It is odd that value '-1' is assigned to the variable 'h' of HRESULT type.
Merge plugins.cpp 992
It's not nice and correct to assign value -1 to a variable whose type is HRESULT.
HRESULT is a 32-bit value divided into three different fields: severity code, device code and error code.
To handle the HRESULT value, such specific constants are used as S_OK, E_FAIL, E_ABORT, etc., while
macros like SUCCEEDED and FAILED are used to check values of the HRESULT type.
The way the value "-1" is written is incorrect. If you want to report some odd bug, you should use value
0x80004005L (Unspecified failure). This constant and others similar to it are described in "WinError.h".
A similar error can be found here:
V543 It is odd that value '-1' is assigned to the variable 'h' of HRESULT type. Merge plugins.cpp 1033
Fragment N4
int TimeSizeCompare::CompareFiles(....)
{
UINT code = DIFFCODE::SAME;
...
if (di.left.size != di.right.size)
{
code &= ~DIFFCODE::SAME;

4. code = DIFFCODE::DIFF;
}
...
}
PVS-Studio's diagnostic rule: V519 The 'code' variable is assigned values twice successively. Perhaps this
is a mistake. Check lines: 79, 80. Merge timesizecompare.cpp 80
This code may be both correct and incorrect: since I'm not familiar with the structure of the WinMerge
project, I cannot know for sure.
Variants are possible:
1) The code contains an error, so the second line should look like this: "code |= DIFFCODE::DIFF;".
2) The code is correct. The first line is unnecessary.
Fragment N5
BOOL CEditDropTargetImpl::
OnDrop (....)
{
bool bDataSupported = false;
m_pOwner->HideDropIndicator ();
if ((!m_pOwner) ||
(!(m_pOwner->QueryEditable ())) ||
(m_pOwner->GetDisableDragAndDrop ()))
...
}
PVS-Studio's diagnostic rule: V595 The 'm_pOwner' pointer was utilized before it was verified against
nullptr. Check lines: 1033, 1035. Merge ccrystaleditview.cpp 1033
As you can see from the "if ((!m_pOwner) ....)" condition, the 'm_pOwner' pointer can be equal to zero.
But before the check is performed, this pointer is already being used in the 'm_pOwner-
>HideDropIndicator()' statement. Thus, a segmentation fault occurs instead of normal null pointer
processing.

5. Fragment N6
BCMenu *BCMenu::FindMenuOption(int nId, UINT& nLoc)
{
...
nLoc = -1;
...
}
BOOL BCMenu::ModifyODMenuW(....)
{
UINT nLoc;
...
BCMenu *psubmenu = FindMenuOption(nID,nLoc);
...
if (psubmenu && nLoc>=0)
mdata = psubmenu->m_MenuList[nLoc];
...
}
PVS-Studio's diagnostic rule: V547 Expression 'nLoc >= 0' is always true. Unsigned type value is always >=
0. Merge bcmenu.cpp 1232
In particular conditions, the FindMenuOption() function returns value -1 in the 'nLoc' variable. Since the
'nLoc' variable is unsigned, the function will actually return 0xFFFFFFFFu.
Now consider the code of the ModifyODMenuW() function. The "nLoc>=0" condition is always true. It
means that the situation when the FindMenuOption() function returns -1 will be processed incorrectly.
Identical errors:
V547 Expression 'nLoc >= 0' is always true. Unsigned type value is always >= 0. Merge bcmenu.cpp 1263
V547 Expression 'nLoc >= 0' is always true. Unsigned type value is always >= 0. Merge bcmenu.cpp 1285
V547 Expression 'nLoc >= 0' is always true. Unsigned type value is always >= 0. Merge bcmenu.cpp 1309
V547 Expression 'loc >= 0' is always true. Unsigned type value is always >= 0. Merge bcmenu.cpp 1561
V547 Expression 'nLoc >= 0' is always true. Unsigned type value is always >= 0. Merge bcmenu.cpp 2409

6. Fragment N7
The program contains the CompareOptions class that has virtual methods but doesn't have a virtual
destructor. Other classes, like DiffutilsOptions, inherit from it. So, absence of a virtual destructor is an
error, though it might not lead to a catastrophe.
PVS-Studio's diagnostic rule: V599 The virtual destructor is not present, although the 'CompareOptions'
class contains virtual functions. Merge diffcontext.cpp 90
It's unreasonable to cite the corresponding code fragments here because they are large.
Note that the PVS-Studio analyzer's diagnostics is rather exact and the tool doesn't swear at each and all
classes which lack a virtual destructor. If you want to understand how the analyzer diagnoses this type
of errors, see its description: V599. The virtual destructor is not present, although the 'Foo' class
contains virtual functions.
Fragment N8
static void StoreDiffData(....)
{
...
GetLog()->Write
(
CLogFile::LCOMPAREDATA,
_T("name=<%s>, leftdir=<%s>, rightdir=<%s>, code=%d"),
di.left.filename.c_str(),
di.left.path.c_str(),
di.right.path.c_str(), di.diffcode
);
pCtxt->m_pCompareStats->AddItem(di.diffcode.diffcode);
...
}
PVS-Studio's diagnostic rule: V510 The 'Write' function is not expected to receive class-type variable as
sixth actual argument. Merge dirscan.cpp 565
The 'di.diffcode' variable is a structure of the DIFFCODE type. Most likely, the correct code was meant to
be the following:
CLogFile::LCOMPAREDATA, _T(...., di.diffcode.diffcode);

7. Fragment N9
static DIFFITEM *AddToList(....,
const DirItem * lent, const DirItem * rent,
....)
{
...
if (lent)
{
...
}
else
{
di->left.filename = rent->filename;
}
if (rent)
{
...
}
PVS-Studio's diagnostic rule: V595 The 'rent' pointer was utilized before it was verified against nullptr.
Check lines: 608, 611. Merge dirscan.cpp 608
The 'rent' pointer is used without checking if it's not equal to zero. Perhaps such a case will never occur
in practice. But still, the check "if (rent)" hints that it is possible in theory.
Fragment N10
String FileFilterHelper::ParseExtensions(....) const
{
String strParsed;
String strPattern;
...

8. strParsed = _T("^");
strPattern = string_makelower(strPattern);
strParsed = strPattern;
...
}
PVS-Studio's diagnostic rule: V519 The 'strParsed' variable is assigned values twice successively. Perhaps
this is a mistake. Check lines: 339, 342. Merge filefilterhelper.cpp 342
The 'strParsed' variable is assigned different values twice in a row. This code either has an error or an
extra assignment. A similar case has been discussed a bit earlier.
Fragment N11
void CLogFile::EnableLogging(BOOL bEnable)
{
...
Write(_T("Path: %sn*******n"), m_strLogPath);
...
}
PVS-Studio's diagnostic rule: V510 The 'Write' function is not expected to receive class-type variable as
second actual argument. Merge logfile.cpp 85
The 'm_strLogPath' variable has the std::wstring type. It means that the log will contain trash. This is the
correct code:
Write(_T("Path: %sn*******n"), m_strLogPath.c_str());
Fragment N12
void CMergeDoc::Computelinediff(
CCrystalTextView * pView1, CCrystalTextView * pView2,
....)
{
...
if (pView1->GetTextBufferEol(line) !=
pView1->GetTextBufferEol(line))

9. ...
}
PVS-Studio's diagnostic rule: V501 There are identical sub-expressions 'pView1->GetTextBufferEol(line)'
to the left and to the right of the '!=' operator. Merge mergedoclinediffs.cpp 216
The 'pView1' variable is used twice. This code, most likely, contains a misprint, so the correct code is the
following:
if (pView1->GetTextBufferEol(line) !=
pView2->GetTextBufferEol(line))
Fragment N13
void CSplashWnd::OnPaint()
{
...
String text = LoadResString(IDS_SPLASH_DEVELOPERS);
// avoid dereference of empty strings and
// the NULL termiated character
if (text.length() >= 0)
{
...
}
PVS-Studio's diagnostic rule: V547 Expression 'text.length() >= 0' is always true. Unsigned type value is
always >= 0. Merge splash.cpp 262
The check "text.length() >= 0" is meaningless. The 'String' type is 'std::wstring'. The
'std::wstring::length()' function always returns a value above or equal to 0.
Fragment N14
void CPreferencesDlg::AddPage(CPropertyPage* pPage, ....)
{
...
m_tcPages.SetItemData(hti, (DWORD)pPage);

10. ...
}
PVS-Studio's diagnostic rule: V205 Explicit conversion of pointer type to 32-bit integer type: (DWORD)
pPage Merge preferencesdlg.cpp 200
Theoretically (but hardly in practice), an object pointed to by 'pPage' can be located outside the first
low-order Gbytes in the 64-bit application. It implies a potential danger, as the pointer is explicitly cast
to the 32-bit type 'DWORD'. This is how this code should look to be safe:
m_tcPages.SetItemData(hti, (DWORD_PTR)pPage);
Conclusion
We have found some other odd fragments in the code. But I cannot tell for sure if they contain errors.
What is the most important, the PVS-Studio analyzer's progress is evident.
If you want to download a full-fledged trial of the analyzer, please follow this link:
http://www.viva64.com/en/pvs-studio-download/. The new trial model will help you to benefit from
the analyzer without purchasing it.
If you have questions regarding this article or the analyzer, please read the post "FAQ for those who
have read our articles" [3]. You are also welcome to ask any questions by writing a letter directly to me
and my colleagues using the feedback page.
References:
1. Evgeniy Ryzhkov. Comparing the general static analysis in Visual Studio 2010 and PVS-Studio by
examples of errors detected in five open source projects. http://www.viva64.com/en/a/0073/
2. Andrey Karpov. Leo Tolstoy and static code analysis. http://www.viva64.com/en/b/0105/
3. Andrey Karpov. FAQ for those who have read our articles. http://www.viva64.com/en/b/0132/