Abstract

This article demonstrates the capabilities of the static code analysis methodology. Readers are offered the chance to study samples of one hundred errors, found in open-source projects in C/C++. All the errors have been found using the PVS-Studio static code analyzer.

Introduction

We won't tire you programmers by making you read texts, and will get on to the error samples right away. Those who want to know what static code analysis is, please follow the link. Those who want to know what PVS-Studio is, and download the trial version, see this page: http://www.viva64.com/en/pvs-studio/.

Samples of errors detected in various open-source projects

The samples of detected errors will be divided into several groups. This division is rather relative. One and the same error can often be referred to as a misprint, and incorrect array handling, at the same time.

Of course, we have taken just a few errors from each of the projects. If we described all the defects found, it would be a reference book. This is the list of analyzed projects:

Array errors and string handling

Array errors, and string handling, are the largest class of defects in C/C++ programs. This is the price for the capability of effective low-level memory handling available to programmers. In the article we will show just a small part of these errors, found by the PVS-Studio analyzer. But we think any C/C++ programmer understands how numerous and insidious they are.

This error was found through the V511: The sizeof() operator returns size of the pointer, and not of the array, in 'sizeof(src)' expression. Splines math_matrix.h 94

Usually programmers expect 'sizeof(src)' to return the size of an array equal to "3*3*sizeof(float)" bytes. But according to the language standard, 'src' is just a pointer, not an array. Thus, the matrix will only be partly copied. The 'memcpy' function will copy 4 or 8 bytes (the pointer size), depending on whether the code is 32-bit or 64-bit.

If you want the whole matrix to be copied, you may pass a reference to the array into the function. This is the correct code:

This error was found through the V579 diagnostic: The strncmp function receives the pointer and its size as arguments. It is probably a mistake. Inspect the third argument. vga vbe.c 57

Calls of the 'strncmp' function in this code compare only the first several characters, not whole strings. The error here is as follows: the sizeof() operator, is used to calculate string lengths, which is absolutely inappropriate in this situation. The sizeof() operator actually calculates the pointer size instead of the number of bytes in a string.

What is most unpleasant and insidious about this error, is that this code almost works as intended. In 99% of cases, comparison of the first several characters is enough. But the remaining 1% can bring you much 'fun' and long hours of debugging.

This error was found through the V512 diagnostic: A call of the 'memcpy' function will lead to a buffer overflow or underflow. tabsrmm utils.cpp 1080

If Unicode-strings are used, one character occupies 2 or 4 bytes (depending on the data model being used in compiler), instead of one byte. Unfortunately, programmers easily forget about this, and you can often see defects like our example, in programs.

The 'CopyMemory' function will copy only part of the L"mailto:" string since it handles bytes, not characters. You can fix the code by using a more appropriate function for string copying or, at least, multiplying number 7 by sizeof(wchar_t).

This error was found through the V557 diagnostic: Array overrun is possible. The value of 'i' index could reach 367. cmlibarchive archive_windows.c 1140, 1142

The error handler itself contains an error. The sizeof() operator returns the array size in bytes, and not the number of items inside it. As a result, the program will try to search much more items than it should in the loop. This is the correct loop:

This error was found through the V541 diagnostic: It is dangerous to print the string 'szOperatingSystem' into itself. stickies camel.cpp 572, 603

An attempt at formatted printing of a string into itself can lead to faults. The result of executing this code depends on the input data, and you cannot predict what will happen. Most likely, the result will be a meaningless string or an Access Violation will occur.

This error can be referred to the category of "code vulnerabilities". In some programs, by feeding special data to code, you can exploit such code fragments to cause a buffer overflow, or other effects an intruder needs.

This error was found through the V518 diagnostic: The 'realloc' function allocates strange amount of memory calculated by 'strlen(expr)'. Perhaps the correct variant is 'strlen(expr) + 1'. fceux cheat.cpp 609

This error is caused by a misprint. It is the 'name' pointer instead of the "name+1" expression that must be the argument of the strlen() function. As a result, the realloc function allocates 2 bytes less memory than needed: one byte is lost because 1 is not added to the string length; another byte is lost because the 'strlen' function calculates the string length skipping the first character.

This error was found through the V512 diagnostic: A call of the memset function will lead to a buffer overflow or underflow. notepadPlus DockingManager.cpp 60

This is one more example of how the number of array items is mixed up with an array size. A multiplication by sizeof(int) is missing.

We can go on and on showing you errors in array handling which we have found in various programs. But we have to stop somewhere.

Undefined behavior

A bit of theory first.

Undefined behavior is a property of certain programming languages (most prominent in C and C++) wherein certain situations, a result is produced which depends on compiler implementation, or specified optimization switches. In other words, the specification does not define the language's behavior in any possible situation but says: "at A condition, the result of B operation is undefined". It is considered a mistake to allow such a situation in your program, even if it is executed well by some particular compiler. Such a program will not be cross platform and may cause failures on a different computer, operating system, and even within different compiler settings.

A sequence point defines any point in a computer program's execution, at which it is guaranteed that all side effects of previous evaluations will have been performed, and no side effects from subsequent evaluations have yet been performed. . To learn more about sequence points and cases of undefined behavior related to sequence points, see this post: http://www.viva64.com/en/t/0065/.

This error was found through the V554 diagnostic: Incorrect use of auto_ptr. The memory allocated with 'new []' will be cleaned using 'delete'. interactive_ui_tests accessibility_win_browsertest.cc 171

This example demonstrates a case where using a smart pointer can cause undefined behavior. It may be expressed through heap damage, program crash, incomplete object destruction or any other failure. The error is as follows: memory is allocated by the new [] operator, and released by the delete operator in the 'auto_ptr' class' destructor:

~auto_ptr() {
delete _Myptr;
}

To fix these issues, you should use a more appropriate class, for instance, boost::scoped_array.

This error was found through the V567 diagnostic: Undefined behavior. The 'pTemp' variable is modified while being used twice between sequence points. me umc_me_cost_func.h 168

This is a classic example of undefined program behavior. It is this construct which is used to demonstrate Undefined behavior in various articles. It is unknown whether 'pTemp' will be incremented by one or not. Two actions of changing pTemp variable's value are located in one sequence point. It means that the compiler may create the following code:

pTemp = pTemp + 1;

pTemp = pTemp;

Or it may create another version of the code:

TMP = pTemp;

pTemp = pTemp + 1;

pTemp = TMP;

Which of the two code versions will be created depends on the compiler and optimization switches.

This error was found through the V567 diagnostic: Undefined behavior. The 'm_nCurrentBitIndex' variable is modified while being used twice at single sequence point. MACLib unbitarrayold.cpp 78

There are no sequence points between two instances of using the 'm_nCurrentBitIndex' variable. It means that the standard does not specify the moment when this variable is incremented. Correspondingly, this code may work differently depending on the compiler and optimization switches.

This error was found through the V564 diagnostic: The '&' operator is applied to the bool type value. You've probably forgotten to include parentheses, or intended to use the '&&' operator. innobase ha_innodb.cc 6789

The programmer wanted a part of the expression to check that a certain bit in the 'create_info->options' variable is equal to zero. But the priority of the '!' operation is higher than that of the '&' operation, this is why the expression works by this algorithm:

((!create_info->options) & HA_LEX_CREATE_TMP_TABLE)

We should use additional parentheses if we want the code to work properly:

This error was found through the V532 diagnostic: Consider inspecting the statement of '*pointer++' pattern. What was probably meant: '(*pointer)++'. emule customautocomplete.cpp 277

If 'pceltFetched' is not a null pointer, the function must increment the variable of the ULONG type this pointer refers to. The error is as follows: the priority of the '++' operation is higher than that of '*' operation (pointer dereferencing). The "*pceltFetched++;" line is identical to the following code:

TMP = pceltFetched + 1;
*pceltFetched;
pceltFetched = TMP;

Virtually it is just increment of the pointer. To make the code correct, we must add parentheses: "(*pceltFetched)++;".

This error was found through the V564 diagnostic: The '&' operator is applied to the bool type value. You've probably forgotten to include parentheses or intended to use the '&&' operator. base platform_file_win.cc 216

Programmers easily forget that the priority of the '!=' operation is higher than that of '&'. This is what happened in our case. As a result, we have the following expression:

info->is_directory =
file_info.dwFileAttributes & (0x00000010 != 0);

Let's simplify the expression:

info->is_directory = file_info.dwFileAttributes & (true);

Let's simplify it once again:

info->is_directory = file_info.dwFileAttributes & 1;

It turns out that we have tested the first bit instead of the fifth bit. To fix this, we need to add parentheses.

This error was found through the V563 diagnostic: It is possible that this 'else' branch must apply to the previous 'if' statement. fire bcmenu.cpp 1853

This is not an error of operation priorities, but one related to it. The programmer did not take into account that the 'else' branch refers to the nearest 'if' operator. We can see the code justification, as if it works like the following algorithm:

This error was found through the V502 diagnostic: Perhaps the '?:' operator works in a different way than it was expected. The '?:' operator has a lower priority than the '|' operator. vm vm_file_win.c 393

Depending on the 'islog' variable's value, the expression must be either equal to "FILE_ATTRIBUTE_NORMAL" or "FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING". But it does not happen. Priority of the '?:' operation is lower than that of '|'. As a result, the code acts as follows:

This error was found through the V502 diagnostic: Perhaps the '?:' operator works in a different way than it was expected. The '?:' operator has a lower priority than the '*' operator. physics dgminkowskiconv.cpp 1061

The error in this code again relates to the low priority of the '?:' operation. The condition for the '?:' operator is expressed by a meaningless subexpression "dgFloat32 (1.0e-24f) * (den > dgFloat32 (0.0f))". Adding parentheses will solve the issue.

By the way, programmers often forget how cunning the '?:' operator is. Here is a post on this topic: "How to make fewer errors at the stage of code writing. Part N2".

Formatted output errors

Examples of these errors are boring and all pretty similar, so we will examine only a few samples. The point is that functions with a variable number of arguments accept actual arguments incompatible with the format string. Any programmer who uses such functions as printf() is familiar with this type of error.

This error was found through the V576 diagnostic: Incorrect format. Consider checking the third actual argument of the 'fprintf' function. The char type argument is expected. regedit regproc.c 293

The fprinf() function must print a character of the char type. But the third argument is a character of the WCHAR type. The user will get an incorrectly generated message. To fix the code, we should replace '%c' with '%C' in the format string.

This error was found through the V576 diagnostic: Incorrect format. A different number of actual arguments is expected while calling '_snprintf' function. Expected: 18. Present: 19. mod_pvs mod_pvs.cpp 308

It is not easy to find an error here at first glance. However, the PVS-Studio analyzer does not get tired, and notices that the function takes more actual arguments than specified in the format string. The reason is that the '%' character is missing in one place. Let's single out this fragment:

This error was found through the V576 diagnostic: Incorrect format. A different number of actual arguments is expected while calling 'printf' function. Expected: 1. Present: 2. RemoteControlSample remotecontrolsample.cpp 792

The error is as follows: the 'tmp' variable is not used in any way when printing the information message.

This error was found through the V520 diagnostic: The comma operator ',' in array index expression '[0, 0]'. graphics3D anyval.cpp 275

The program prints meaningless values instead of the matrix. You may write such a code when you work with different programming languages, and sometimes forget how to access an item in a two-dimensional array in the C language.

Let's see how the 'm[0, 1]' expression works. At first, expression"0, 1" is calculated. The result of this expression is 1. Then the 'operator[]' function is called in the Matrix3 class. The function takes the actual argument 1, and returns the pointer to the first string in the matrix. It is the value of this pointer that will be printed by the 'printf()' function though it expects a value of the float-type.

Examples of misprints found in code

A lot of programming errors are caused by misprints. Most of these errors are quickly detected at the early stages of testing. But there are some defects of this kind that remain in code for a long time, causing troubles both to programmers and users.

You can decrease the frequency of these errors using the PVS-Studio analyzer. It will find them before testing starts, which will significantly reduce the cost of defect detection and elimination.

This error was found through the V501 diagnostic: There are identical sub-expressions 'LBO->hasNoUnsignedWrap ()' to the left and to the right of the '&&' operator. LLVMAnalysis instructionsimplify.cpp 1891

There is a misprint when using variables with similar names. In the first line, both LBO and RBO variables must be used. This is the correct code:

This error was found through the V575 diagnostic: The 'memcmp' function processes '0' elements. Inspect the 'third' argument. graphics3D matrix4.cpp 269

One closing parenthesis is in the wrong place. It turns out that the size of the memory area being compared, is calculated by the "sizeof(Matrix4) == 0" expression. This expression always has the 'false' result. Then 'false' turns into an integer value equal to 0. This is the correct code:

This error was found through the V568 diagnostic: It's odd that the argument of sizeof() operator is the 'sizeof (SECURITY_ATTRIBUTES)' expression. libhttpd util_win32.c 115

The field 'nLength' must contain the size of the 'SECURITY_ATTRIBUTES' structure. There is a misprint in the code: the 'sizeof' operator is used twice. As a result, the field 'nLength' stores a size of the 'size_t' type. This is the correct code:

This error was found through the V561 diagnostic: It's probably better to assign value to 'x' variable than to declare it anew. Previous declaration: ines.cpp, line 960. fceuxines.cpp 962

The 'x' variable must store information whether or not a file was opened successfully. Because of a misprint, a new variable named 'x' is created and initialized instead of assigning 1 to the existing variable. This is how the correct code must look:

This error was found through the V529 diagnostic: Odd semicolon ';' after 'for' operator. settings.c 483

All the C and C++ programmers know how dangerous an extra semicolon ';' is. Unfortunately, this knowledge does not prevent them from making such misprints. There is an extra semicolon after the first 'for' operator, which makes this program fragment unable to execute.

This error was found through the V557 diagnostic: Array overrun is possible. The '30' index is pointing beyond array boundaries. avs_enc umc_avs_enc_compressor_enc_b.cpp 495

Consider this fragment: "m_pMbInfo->refIdx[dir][30]". Because of a misprint, number 30 is written instead of index 3. By the way, this sample shows well how relative our division of errors into categories is. This error might well be referred to the category "Errors in array and string handling". The division is relative, and is made to show the diversity of errors the PVS-Studio analyzer can detect.

Example 16. ReactOS project. Misprint in a macro.

#define SWAP(a,b,c) c = a;\
a = b;\
a = c

This error was found through the V519 diagnostic: The 'v2' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 343, 343. win32k gradient.c 343

It is a rather funny misprint in a macro intended to swap values in two variables. Look closely at the code, and you will see what I mean. This is the correct code:

The error has been found with rule V521: Such expressions using the ',' operator are dangerous. Make sure the expression is correct. bspc l_bsp_q1.c 136

It's a funny misprint. Look at the line in the middle of the code. ',' written instead of '*'. As a result, the 'sizeof(q1_dedge_t)' value is always added to the 'q1_allocatedbspmem' variable. I have no suggestions how this misprint could have occurred.

This error has been found with rule V588: The expression of the 'A =+ B' kind is utilized. Consider reviewing it, as it is possible that 'A += B' was meant. libxml xpath.c 12676

In one place, "=+" is written instead of "+=" by mistake. They look similar but the result is quite different. Such errors are rather difficult to find just by reviewing the code.

Many errors in software are caused by misprints. There are many more errors of this kind, than programmers think. We could go on and on in this section, but we've decide to stop at the 18th3:09 PM example.

This error was found through the V530 diagnostic: The return value of the function 'remove' is required to be utilized. contextmenu.cpp 442

The std::remove function does not remove items from the container. It only shifts the items, and returns the iterator to the beginning of trash. Assume we have a vector<int> container that contains items 1,2,3,1,2,3,1,2,3. If we execute the code "remove( v.begin(), v.end(), 2 )", the container will contain items 1,3,1,3,X,X,X, where X is trash. The function will return the iterator to the first trash item, so if we want to remove these trash items, we need to write the code: "v.erase(remove(v.begin(), v.end(), 2), v.end())".

This error was found through the V530 diagnostic: The return value of function 'empty' is required to be utilized. mailmsg.cpp 40

The error here is as follows: the vector::empty() function is called by mistake instead of vector::clear(), and the array's contents remain the same. It is a very frequent error because the words 'clear' and 'empty' are rather close in meaning, and you might easily mix them up.

This error was found through the V530 diagnostic: The return value of function 'empty' is required to be utilized WinMerge DirActions.cpp 1307, 1308

Again, the reason is in using the empty() function instead of clear(). We could cite examples of such errors from other projects as well: InstantVNC, IPP Samples, Chromium, Intel AMT SDK, etc. Unfortunately, all these samples are alike, and there is nothing interesting about examining them. But trust me, you can see these defects in serious projects developed by professional programmers.

This error was found through the V505 diagnostic: The 'alloca' function is used inside the loop. This can quickly overflow stack. ri polygons.cpp 1120

The alloca function allocates memory inside the stack, so calling it many times inside the loop body may suddenly cause a stack overflow. And we have several nested loops here. This code may exhaust stack memory very quickly.

This error was found through the V503 diagnostic: This is a nonsensical comparison: pointer < 0. ipprsample ippr_sample.cpp 501

I do not know how it happened, but there are 3 characters "[i]" missing in this code. As a result, the code performs a meaningless check that the pointer is below zero instead of checking the mask array.

This error was found through the V550 diagnostic: An odd precise comparison: x == 0. It's probably better to use a comparison with defined precision: fabs(A - B) '<' Epsilon. clock_dll sunalgo.cpp 155

It is strange to expect that the result will be strictly 0 after executing all these complex calculations using 'sin' and 'cos' functions. Most likely, there must be comparison to be performed with certain accuracy.

This error was found through the V519 diagnostic: The 'radius' object is assigned values twice successively. Perhaps this is a mistake. Lugaru gamedraw.cpp 1505

The programmer must have deliberately written value 110 into the 'radius' variable for the sake of experiment, and then forgot to remove this line. As a result, we have a meaningless, and maybe even invalid, code.

This error was found through the V532 diagnostic: Consider inspecting the statement of '*pointer++' pattern. What was probably meant: '(*pointer)++'. mpeg2_dec umc_mpeg2_dec.cpp 59

The loop body is probably incomplete, because it is meaningless in the current form.

Always true, or always false conditions

This is a very large, and widely-spread type of error. These errors also vary greatly depending on the importance level. To non-dangerous errors we may refer incorrect conditions in ASSERT, which actually do not check anything. To dangerous errors, incorrect checks of buffer size or index size are referred.

This error was found through the V547 diagnostic: Expression 'pBytes [ 0 ] == 0xEF' is always false. The value range of signed char type: [-128, 127]. Shareaza remote.cpp 350

In this code, the 'TCHAR' type is the 'char' type. The value range of char is from -128 to 127 inclusive. Value 0xEF in the variable of the char type is nothing other than number -17. When comparing the char variable with number 0xEF, its type is extended up to the 'int' type. But the value still lies inside the range [-128..127]. The "pBytes[0] == 0xEF" ("-17 == 0xEF") condition is always false, and the program does not work as intended.

This error was found through the V547 diagnostic: Expression '* utf8CheckBuf == 0xC0' is always false. The value range of signed char type: [-128, 127]. tortoiseblame.cpp 310

While the defect in the previous example seems to be caused through mere inattention, in this case it is not so. Here is another identical example where a condition is always false. This is a very widely-spread type of error in various projects.

An attempt to check that a socket was created successfully is performed incorrectly. If a socket cannot be created, this situation is not handled in any way. To make the check work correctly, we should use the INVALID_SOCKET constant:

This error was found through the V547 diagnostic: Expression '*string != 0 || *string != '_'' is always true. Probably the '&&' operator should be used here. icui18n ucol_sit.cpp 242

The condition contains a logical error. The "(*string != 0 || *string != '_')" subexpression is always true. It is impossible that one and the same string character is not equal to 0 and '_' at a time.

The (--size >= 0) condition is always true, since the size variable has the unsigned type. It means that if two sequences being compared are alike, we will get an overflow which will in its turn cause Access Violation, or other program failures.

This error was found through the V545 diagnostic: Such conditional expression of 'if' operator is incorrect for the HRESULT type value '(HRESULT) 0L'. The SUCCEEDED or FAILED macro should be used instead. phonon_ds9 qbasefilter.cpp 60

The check condition is represented by the S_OK constant. Since S_OK is 0, the AddRef() function will never be called. This is how this check should look: if (hr == S_OK).

This error was found through the V547 diagnostic: Expression 'csd < 0' is always false. Unsigned type value is never < 0. libhttpd child.c 404

Socket handling errors very often emerge in cross platform programs built under Windows. In Linux, socket descriptors are represented by the signed type, while in Windows it is the unsigned type. Programmers often forget about this, and check the error status by comparing the value to 0. This is incorrect; you must use specialized constants.

This error was found through the V517 diagnostic: The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. Check lines: 2303, 2305. lrelease profileevaluator.cpp 2303

In the string we have marked, there must be the text "ver == QSysInfo::WV_2003". Because of this error, the "ret = QLatin1String("Win2003")" statement will never be executed.

Code vulnerabilities

Of course, errors leading to code vulnerabilities are actually misprints, incorrect conditions, and incorrect array handling. But we decided to single out certain errors into a separate group, because they relate to the notion of software vulnerabilities. An intruder, using such errors, can try to disturb program operation, perform an attack to gain extended rights, or carry out any other actions he/she needs.

This error was found through the V528 diagnostic: It is odd that the pointer to the 'char' type is compared with the '\0' value. What was probably meant: *m_szPassword != '\0'. UTMail ut_crammd5.cpp 333

This code fragment must check that the pointer to the password is not equal to NULL, and that the string is not empty. But instead, the code checks twice that the pointer is not equal to NULL. The check of the string does not work. The "if (m_szPassword != '\0')" condition was intended to check that there is a terminal null in the very beginning of the string, which means that the string is empty. But a pointer dereferencing operation is missing here, and it is the pointer itself which is compared to zero. This is the correct code:

This error was found through the V512 diagnostic: A call of the 'memset' function will lead to a buffer overflow or underflow. CSmtp md5.cpp 212

For security purposes, the function tries to clear the buffer containing sensitive information. But it fails. Only the first byte will be cleared in the buffer. The error is this: the 'sizeof' operator calculates the size of the 'uint1' type instead of buffer. This is the correct code:

memset (buffer, 0, sizeof(buffer));

Generally, errors of incomplete memory clearing are rather frequent. Consider some other cases like this.

This error was found through the diagnostics: V528 It is odd that the pointer to the 'char' type is compared with the '\0' value. What was probably meant: *str != '\0'. clist_modern modern_skinbutton.cpp 282

V528 It is odd that the pointer to the 'char' type is compared with the '\0' value. What was probably meant: *endstr != '\0'. clist_modern modern_skinbutton.cpp 283

This code is rather dangerous, because it incorrectly determines the string end. It may cause a string overflow and, as a consequence, an Access Violation exception. The error lies here: "str!='\0'" and here: "endstr!='\0'". A pointer dereferencing operation is missing. This is the correct code:

This error was found through the V527 diagnostic: It is odd that the '\0' value is assigned to the 'char' type pointer. What was probably meant: *new_key [79] = '\0'. graphics3D pngwutil.c 1283

This sample demonstrates a mistake where the programmer accidentally clears the pointer instead of truncating the string length. The point is that 'new_key' is a pointer to a string. And it means that we should write our code as follows, to truncate it to 79 characters:

Suppose the whole string consists only of spaces. While searching the characters, the program will reach the null item of the string, and the 'loop' variable will equal zero. Then it will be decremented once again. Since this variable is of unsigned type, its value will be 0xFFFFFFFFu or 0xFFFFFFFFFFFFFFFFu (depending on the architecture). This value is 'naturally >= 0', and a new loop iteration will start. There will be an attempt at memory access by szString[0xFFFFFFFFu] address - the consequences of this are familiar to every C/C++ programmer.

This error has been found with rule V597: The compiler could delete the 'memset' function call, which is used to flush 'kappa' buffer. The RtlSecureZeroMemory() function should be used to erase the private data. cryptlib cast.cpp 293

The problem is in the memset() function. The arguments passed into the function are correct. If a programmer looks at how the debug-version of this code works in the debugger, he/she won't notice the trouble either. The error occurs in the release version of the project. The data that should have been cleared will remain in memory. The reason is that the compiler has the right to delete the call of the memset() function during optimization, and this is what it does. If you want know why it happens, read the article "Overwriting memory - why?".

Copy-Paste

Developers should not also underestimate Copy-Paste errors, as well as common misprints. They are very, very common. Programmers spend a lot of time debugging these errors.

Of course, misprints and Copy-Paste errors are similar, but there is a difference between them, which caused us to place them into different groups in this article. Misprints often result in using the wrong variable instead of the needed one. And in the case of copy-paste, programmers simply forget to edit copied and pasted lines.

This error was found through the V525 diagnostic: The code containing the collection of similar blocks. Check items '11', '12', '13', '13' in lines 716, 717, 718, 719. id3 editor.c 716

The four similar lines must have appeared in the code through the copy-paste method. When the programmer started editing the indices, he/she made a mistake that causes zero to be written into 'fhead[13] ' twice, and not be written into 'fhead[14] '.

This error was found through the V524 diagnostic: It is odd that the 'GetDbgHelpVersion' function is fully equivalent to the 'GetImageHlpVersion' function (SymbolEngine.h, line 98). symbolengine.h 105

The 'GetImageHlpVersion' function must have appeared through copying and pasting the 'GetInMemoryFileVersion' function. The error is as follows: the programmer forgot to fix the file name in the copied and pasted function. This is the correct code:

This error was found through the V524 diagnostic: It is odd that the body of 'clearTopDownPointers' function is fully equivalent to the body of 'clearBottomUpPointers' function (ObjCARC.cpp, line 1318). LLVMScalarOpts objcarc.cpp 1322

The body of the clearBottomUpPointers function seems to be incorrect; this function should be written as follows:

This error was found through the V519 diagnostic: The 'x1' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 2218, 2219. Qt3Support q3canvas.cpp 2219

The first line is absolutely correct, and swaps values in the x1 and x2 variables. In the second line, variables y1 and y2 must be swapped. This line is probably a copy of the previous one. All the 'x' letters must be replaced with letters 'y'. Unfortunately, the programmer forgot to do that in one place: "... x1=y2; ...".

This error was found through the V501 diagnostic: There are identical sub-expressions 'm_pContext->m_seqLayerHeader->heightMB' to the left and to the right of the '&&' operator. vc1_dec umc_vc1_video_decoder.cpp 1347

Late check of null pointers

C/C++ programmers have to check numerous pointers all the time, to make sure that they are not equal to zero. Since there are many of these check to be made, the chance of making a mistake is also quite high. It often happens that a pointer is used first, and only then is compared to NULL. Errors of this type reveal themselves very rarely. Usually the program works correctly in standard mode, and fails only in the case of a non-standard situation. Instead of correctly processing a null pointer in normal mode, an Access Violation will occur, and an exception will be thrown.

This error was found through the V536 diagnostic: Be advised that the utilized constant value is represented by an octal form. Oct: 0713, Dec: 459. IFF plugins pixelservices.inl 146

If you examine the second function, you will see that the programmer intended to use number 713, not 0713. Number 0713 is declared in the octal numeral system. You can easily forget about it if you seldom use octal constants.

This error was found through the V535 diagnostic: The variable 'c' is being used for this loop, and for the outer loop. jpegcodec jpegdec.cpp 4652

One and the same variable is used for the outer loop and the inner loop. As a result, this code will handle only part of the data, or cause an infinite loop.

Example 3. Quake-III-Arena project. Missing return.

static ID_INLINE int BigLong(int l)
{ LongSwap(l); }

This error has been found with rule V591: Non-void function should return a value. botlib q_shared.h 155

This code is written in C. This means that the compiler doesn't require that return should be necessarily present. But it is absolutely necessary here. However, the code can work well, due to sheer luck. Everything depends on what the EAX register contains. But it's just luck and nothing more. The function body should have been written this way: { return LongSwap(l); }.

This error has been found with rule V590: Consider inspecting this expression. The expression is excessive, or contains a misprint. Notepad++ notepad_plus.cpp 853

Perhaps this error is just a misprint, but it could also have appeared during factoring. However, it is obvious. The condition can be simplified: if (langT == L_PHP). It means that the code must have looked this way: