90 Errors in Open-Source Projects

Abstract

There are actually 91 errors described in the article, but number 90 looks nicer in the title. The article is intended for C/C++ programmers, but developers working with other languages may also find it interesting.

The materials collected in this article will be useful for authors of articles, books and blogs. Examples of errors can be used to demonstrate advantages of different programming styles - for instance, why you should not try to make your code shorter by writing long expressions.

Examples of errors detected in various open-source projects

We regularly check known and little-known open-source projects. We do it with the purpose to get an opportunity to write a corresponding advertisement item and test the PVS-Studio analyzer on new code. Many readers ask if we tell projects' authors about errors. Surely. And sometimes it happens that we get a new customer after that.

All the examples of detected errors are divided into several groups. This division is rather relative. One and the same error can be referred to misprints, vulnerabilities and incorrect array handling at a time. That's why we have arranged the errors in different categories just to show you that the analyzer can detect a wide range of various defects.

We took only a few errors from each of the projects we have checked, of course. If we describe all the detected issues, the article will turn into a reference book. Here is a list of projects we have analyzed:

Errors of array and string handling

Errors of array 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.

The 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 be copied only partly. 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:

The 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 this: the sizeof() operator, absolutely inappropriate in this situation, is used to calculate string lengths. The sizeof() operator actually calculates the pointer size instead of the number of bytes in a string.

What is the 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 debugging.

The error was found through the V557 diagnostic: Array overrun is possible. The '9' index is pointing beyond array bound. VirtualDub f_convolute.cpp 73

This is one of the simplest errors causing an array overrun. Index 9 is used explicitly, though the last item's index is 8. The author probably forgot, while writing this code, that array items in C/C++ are numbered starting with zero, not one. It happens when you have to switch between different programming languages.

The 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 it, 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).

The 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 of formatted printing of a string into itself can lead to bad consequences. 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 "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.

The 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.

90 Errors in Open-Source Projects

Undefined behavior

A bit of theory at first.

Undefined behavior is a property of certain programming languages (most prominent in C and C++) to produce a result in certain situations that depends on compiler implementation or specified optimization switches. In other words, the specification does not define the language's behavior in any possible situations 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 at some particular compiler. Such a program will not be crossplatform and may cause failures on a different computer, operating system and even at different compiler's settings.

A sequence point in programming is any point in a program where it is guaranteed that the side effects of all the previous calculations have already emerged while there are no side effects of the following calculations yet. 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/.

The 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 the case when 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 this: 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.

The 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.

The 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.

The error was found through the V564 diagnostic: The '&' operator is applied to 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, that's 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:
(!(create_info->options & HA_LEX_CREATE_TMP_TABLE))

The error was found through the V532 diagnostic: Consider inspecting the statement of '*pointer++' pattern. 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 this: 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)++;".

The error was found through the V564 diagnostic: The '&' operator is applied to 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.

The 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 relative to it. The programmer does not take into account that the 'else' branch refers to the nearest 'if' operator. We can see that the code justification as if it works by the following algorithm:

The 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:

The 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 alike, 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 errors.

The 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.

The 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 sight. 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:

The 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 this: the 'tmp' variable is not used in any way when printing the information message.

The 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 make these errors much fewer using the PVS-Studio analyzer. It will find them before testing starts, which will significantly reduce the cost of defect detection and elimination.

The 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:

The 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 a 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:

The 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:

The error was found through the V561 diagnostic: It's probably better to assign value to 'x' variable than to declare it anew. Previous daclaration: 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:

The 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.

The error was found through the V557 diagnostic: Array overrun is possible. The '30' index is pointing beyond array bound. 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 of array and string handling". The division is relative and is made to show 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

The 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:

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

This time we did not manage to stop at the 13-th example: so many errors in software are caused by misprints. There are much more errors of this kind than programmers think. We could go on and on in this section but we decide to stop at the 16-th example at last.

The error was found through the V530 diagnostic: The return value of 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 some 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())".

The 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 this: 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.

The 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.

The 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.

The 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.

The 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.

The 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.

The error was found through the V532 diagnostic: Consider inspecting the statement of '*pointer++' pattern. 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

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

The 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 else 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.

The 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 errors 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:

The 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 that will in its turn cause Access Violation or other program failures.

The 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 must look: if (hr == S_OK).

The 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 crossplatform 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.

The 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.

90 Errors in Open-Source Projects

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.

The error was found through the V528 diagnostic: It is odd that pointer to 'char' type is compared with the '\0' value. 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:

The 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.

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

V528 It is odd that pointer to 'char' type is compared with the '\0' value. 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:

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

This sample demonstrates a mistake when 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 to 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 of memory access by szString[0xFFFFFFFFu] address - the consequences of this are familiar to every C/C++ programmer.

Copy-Paste

Developers should not also underestimate Copy-Paste errors as well as common misprints. They are very-very numerous. Programmers spend much time on debugging them.

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

The 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 indexes, he/she made a mistake that causes zero to be written into 'fhead[13] ' twice and not be written into 'fhead[14] '.

The 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 this: the programmer forgot to fix the file name in the copied and pasted function. This is the correct code:

The 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:

The 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; ...".

The 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

The 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.

References

About the Author

Andrey Karpov

Andrey Karpov is technical manager of the OOO "Program Verification Systems" (Co Ltd) company developing the PVS-Studio tool which is a package of static code analyzers integrating into the Visual Studio development environment.

PVS-Studio is a static analyzer that detects errors in source code of C/C++ applications. There are 3 sets of rules included into PVS-Studio:

Andrey Karpov is also the author of many articles on the topic of 64-bit and parallel software development. To learn more about the PVS-Studio tool and sources concerning 64-bit and parallel software development, please visit the www.viva64.com site.

Top White Papers and Webcasts

U.S. companies are desperately trying to recruit and hire skilled software engineers and developers, but there is simply not enough quality talent to go around. Tiempo Development is a nearshore software development company. Our headquarters are in AZ, but we are a pioneer and leader in outsourcing to Mexico, based on our three software development centers there. We have a proven process and we are experts at providing our customers with powerful solutions. We transform ideas into reality.

When individual departments procure cloud service for their own use, they usually don't consider the hazardous organization-wide implications. Read this paper to learn best practices for setting up an internal, IT-based cloud brokerage function that service the entire organization. Find out how this approach enables you to retain top-down visibility and control of network security and manage the impact of cloud traffic on your WAN.