A Collection of Examples of 64-bit Errors in Real Programs
Upcoming SlideShare
Loading in...5
×
 

A Collection of Examples of 64-bit Errors in Real Programs

on

  • 616 views

This article is the most complete collection of examples of 64-bit errors in the C and C++ languages. The article is intended for Windows-application developers who use Visual C++, however, it will be ...

This article is the most complete collection of examples of 64-bit errors in the C and C++ languages. The article is intended for Windows-application developers who use Visual C++, however, it will be useful for other programmers as well.

Statistics

Views

Total Views
616
Views on SlideShare
616
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    A Collection of Examples of 64-bit Errors in Real Programs A Collection of Examples of 64-bit Errors in Real Programs Document Transcript

    • A Collection of Examples of 64-bit Errorsin Real ProgramsAuthor: Andrey KarpovDate: 29.06.2010AbstractThis article is the most complete collection of examples of 64-bit errors in the C and C++ languages. Thearticle is intended for Windows-application developers who use Visual C++, however, it will be useful forother programmers as well.IntroductionOur company OOO "Program Verification Systems" develops a special static analyzer Viva64 that detects64-bit errors in the code of C/C++ applications. During this development process we constantly enlargeour collection of examples of 64-bit defects, so we decided to gather the most interesting ones in thisarticle. Here you will find examples both taken directly from the code of real applications and composedsynthetically relying on real code since such errors are too "extended" throughout the native code.The article only demonstrates various types of 64-bit errors and does not describe methods of detectingand preventing them. If you want to know how to diagnose and fix defects in 64-bit programs, pleasesee the following sources: 1. Lessons on development of 64-bit C/C++ applications [1]; 2. About size_t and ptrdiff_t [2]; 3. 20 issues of porting C++ code on the 64-bit platform [3]; 4. PVS-Studio Tutorial [4]; 5. A 64-bit horse that can count [5].You may also try the demo version of the PVS-Studio tool that includes the Viva64 static code analyzerwhich detects almost all the errors described in this article. The demo version of the tool can bedownloaded here: http://www.viva64.com/pvs-studio/download/.Example 1. Buffer overflowstruct STRUCT_1{ int *a;};
    • struct STRUCT_2{ int x;};...STRUCT_1 Abcd;STRUCT_2 Qwer;memset(&Abcd, 0, sizeof(Abcd));memset(&Qwer, 0, sizeof(Abcd));In this program, two objects of the STRUCT_1 and STRUCT_2 types are defined which must be zeroed(all the fields must be initialized with nulls) before being used. While implementing the initialization, theprogrammer decided to copy a similar line and replaced "&Abcd" with "&Qwer" in it. But he forgot toreplace "sizeof(Abcd)" with "sizeof(Qwer)". Due to mere luck, the sizes of the STRUCT_1 and STRUCT_2structures coincided on a 32-bit system and the code has been working correctly for a long time.When porting the code on the 64-bit system, the size of the Abcd structure increased and it resulted in abuffer overflow error (see Figure 1).
    • Figure 1 - Schematic explanation of the buffer overflow exampleSuch an error is difficult to detect if the data which should be used much later get spoiled.Example 2. Unnecessary type conversionschar *buffer;char *curr_pos;int length;...while( (*(curr_pos++) != 0x0a) && ((UINT)curr_pos - (UINT)buffer < (UINT)length) );This code is bad yet it is real. Its task is to search for the end of the line marked with the 0x0A symbol.The code will not process lines longer than INT_MAX characters since the length variable has the inttype. But we are interested in another error, so lets assume that the program works with a small bufferand it is correct to use the int type here.
    • The problem is that the buffer and curr_pos pointers might lie outside the first 4 Gbytes of the addressspace in a 64-bit system. In this case, the explicit conversion of the pointers to the UINT type willthrough away the significant bits and the algorithm will be violated (see Figure 2).Figure 2 - Incorrect calculations when searching for the terminal symbolWhat is unpleasant about this error is that the code can work for a long time as long as buffer memory isallocated within the first four Gbytes of the address space. To fix the error, you should remove the typeconversions which are absolutely unnecessary:while(curr_pos - buffer < length && *curr_pos != n)
    • curr_pos++;Example 3. Incorrect #ifdefsYou may often see code fragments wrapped in #ifdef - -#else - #endif constructs in programs with longhistory. When porting programs to the new architecture, the incorrectly written conditions might resultin compilation of other code fragments than the developers intended before (see Figure 3). Forexample:#ifdef _WIN32 // Win32 code cout << "This is Win32" << endl;#else // Win16 code cout << "This is Win16" << endl;#endif//Alternative incorrect variant:#ifdef _WIN16 // Win16 code cout << "This is Win16" << endl;#else // Win32 code cout << "This is Win32" << endl;#endif
    • Figure 3 - Two variants - this is too littleIt is dangerous to rely on the #else variant in such cases. It is better to explicitly check behavior for eachcase (see Figure 4) and add a message about a compilation error into the #else branch:#if defined _M_X64 // Win64 code (Intel 64) cout << "This is Win64" << endl;#elif defined _WIN32 // Win32 code
    • cout << "This is Win32" << endl;#elif defined _WIN16 // Win16 code cout << "This is Win16" << endl;#else static_assert(false, "Unknown platform ");#endif
    • Figure 4 - All the possible compilation ways are checkedExample 4. Confusion of int and int*In obsolete programs, especially those written in C, you may often see code fragments where a pointeris stored in the int type. However, sometimes it is done through lack of attention rather than onpurpose. Lets consider an example with confusion caused by using the int type and a pointer to the inttype:int GlobalInt = 1;void GetValue(int **x)
    • { *x = &GlobalInt;}void SetValue(int *x){ GlobalInt = *x;}...int XX;GetValue((int **)&XX);SetValue((int *)XX);In this sample, the XX variable is used as a buffer to store the pointer. This code will work correctly onthose 32-bit systems where the size of the pointer coincides with the int types size. In a 64-bit system,this code is incorrect and the callGetValue((int **)&XX);will cause corruption of the 4 bytes of memory next to the XX variable (see Figure 5).
    • Figure 5 - Memory corruption near the XX variableThis code was being written either by a novice or in a hurry. The explicit type conversions signal that thecompiler was resisting the programmer till the last hinting to him that the pointer and the int type aredifferent entities. But crude force won.Correction of this error is elementary and lies in choosing an appropriate type for the XX variable. Theexplicit type conversion becomes no longer necessary:int *XX;GetValue(&XX);SetValue(XX);Example 5. Using deprecated (obsolete) functionsSome API-functions can be dangerous when developing 64-bit applications although they werecomposed for compatibility purpose. The functions SetWindowLong and GetWindowLong are a typicalexample of these. You may often see the following code fragment in programs:SetWindowLong(window, 0, (LONG)this);...Win32Window* this_window = (Win32Window*)GetWindowLong(window, 0);You cannot reproach the programmer who once wrote this code for anything. During the developmentprocess, he created this code relying on his experience and MSDN five or ten years ago and it is
    • absolutely correct from the viewpoint of the 32-bit Windows. The prototype of these functions looks asfollows:LONG WINAPI SetWindowLong(HWND hWnd, int nIndex, LONG dwNewLong);LONG WINAPI GetWindowLong(HWND hWnd, int nIndex);The explicit conversion of the pointer to the LONG type is also justified since the sizes of the pointer andthe LONG type coincide in Win32 systems. However, I think you understand that these type conversionsmight cause a crash or false behavior of the program after its being recompiled in the 64-bit version.What is unpleasant about this error is that it occurs irregularly or very rarely at all. Whether the errorwill reveal itself or not depends upon the area of memory where the object is created referred to by the"this" pointer. If the object is created in the 4 least significant Gbytes of the address space, the 64-bitprogram can work correctly. The error might occur unexpectedly in a long time when the objects willstart to be created outside the first four Gbytes due to memory allocation.In a 64-bit system, you can use the SetWindowLong/GetWindowLong functions only if the programreally saves some values of the LONG, int, bool types and the like. If you need to work with pointers, youshould use the following extended function versions: SetWindowLongPtr/GetWindowLongPtr.However, I should recommend you to use new functions anyway in order to avoid new errors in future.Examples with the SetWindowLong and GetWindowLong functions are classic and cited almost in all thearticles on 64-bit software development. But you should understand that it is not only these functionsthat you must consider. Among other functions are: SetClassLong, GetClassLong, GetFileSize,EnumProcessModules, GlobalMemoryStatus (see Figure 6).Figure 6 - A table with the names of some obsolete and contemporary functionsExample 6. Truncation of values at an implicit type conversionAn implicit conversion of the size_t type to the unsigned type and similar conversions are easilydiagnosed by the compilers warnings. But in large programs, such warnings might be easily missed. Letsconsider an example similar to real code where the warning was ignored because it seemed to theprogrammer that nothing bad might happen when working with short strings.bool Find(const ArrayOfStrings &arrStr){
    • ArrayOfStrings::const_iterator it; for (it = arrStr.begin(); it != arrStr.end(); ++it) { unsigned n = it->find("ABC"); // Truncation if (n != string::npos) return true; } return false;};The function searches for the text "ABC" in the array of strings and returns true if at least one stringcontains the sequence "ABC". After recompilation of the 64-bit version of the code, this function willalways return true.The "string::npos" constant has value 0xFFFFFFFFFFFFFFFF of the size_t type in the 64-bit system. Whenputting this value into the "n" variable of the unsigned type, it is truncated to 0xFFFFFFFF. As a result,the condition " n != string::npos" is always true since 0xFFFFFFFFFFFFFFFF is not equal to 0xFFFFFFFF(see Figure 7).
    • Figure 7 - Schematic explanation of the value truncation errorThe correction of this error is elementary - you just should consider the compilers warnings:for (auto it = arrStr.begin(); it != arrStr.end(); ++it){ auto n = it->find("ABC"); if (n != string::npos) return true;}return false;Example 7. Undefined functions in CDespite the passing years, programs or some of their parts written in C remain as large as life. The codeof these programs is much more subject to 64-bit errors because of less strict rules of type checking inthe C language.In C, you can use functions without preliminary declaration. Lets look at an interesting example of a 64-bit error related to this feature. Lets first consider the correct version of the code where allocationtakes place and three arrays, one Gbyte each, are used:#include <stdlib.h>
    • void test(){ const size_t Gbyte = 1024 * 1024 * 1024; size_t i; char *Pointers[3]; // Allocate for (i = 0; i != 3; ++i) Pointers[i] = (char *)malloc(Gbyte); // Use for (i = 0; i != 3; ++i) Pointers[i][0] = 1; // Free for (i = 0; i != 3; ++i) free(Pointers[i]);}This code will correctly allocate memory, write one into the first item of each array and free theoccupied memory. The code is absolutely correct on a 64-bit system.Now lets remove or write a comment on the line "#include <stdlib.h>". The code will be still compiledbut the program will crash right after the launch. If the header file "stdlib.h" is not included in, the Ccompiler supposes that the malloc function will return the int type. The first two instances of memoryallocation will be most likely successful. When the memory is being allocated for the third time, themalloc function will return the array address outside the first 2 Gbytes. Since the compiler supposes thatthe functions result has the int type, it will interpret the result incorrectly and save an incorrect value ofthe pointer in the Pointers array.Lets consider the assembler code generated by the Visual C++ compiler for the 64-bit Debug version. Inthe beginning, there is the correct code that will be generated when the definition of the mallocfunction is present (i.e. the "stdlib.h" file is included in):Pointers[i] = (char *)malloc(Gbyte);mov rcx,qword ptr [Gbyte]call qword ptr [__imp_malloc (14000A518h)]mov rcx,qword ptr [i]mov qword ptr Pointers[rcx*8],raxNow lets look at the incorrect code when the definition of the malloc function is absent:Pointers[i] = (char *)malloc(Gbyte);mov rcx,qword ptr [Gbyte]call malloc (1400011A6h)cdqemov rcx,qword ptr [i]
    • mov qword ptr Pointers[rcx*8],raxNote that there is the CDQE (Convert doubleword to quadword) instruction. The compiler supposes thatthe result is contained in the eax register and extends it to a 64-bit value in order to write it into thePointers array. Correspondingly, the most significant bits of the rax register will be lost. Even if theaddress of the allocated memory lies within the first four Gbytes, we will still get an incorrect result ifthe most significant bit of the eax register equals 1. For instance, address 0x81000000 will turn into0xFFFFFFFF81000000.Example 8. Remains of dinosaurs in large and old programsLarge old program systems that have been developing for tens of years are abound in various atavismsand code fragments written with popular paradigms and styles of different years. In such systems, youcan watch the evolution of programming languages when the oldest fragments are written in C and thefreshest ones contain complex templates of Alexandrescu style.Figure 8 - Dinosaur excavationsThere are atavisms referring to 64 bits as well. To be more exact, these are atavisms that preventcontemporary 64-bit code from correct work. Consider an example:// beyond this, assume a programming error#define MAX_ALLOCATION 0xc0000000void *malloc_zone_calloc(malloc_zone_t *zone, size_t num_items, size_t size){ void *ptr; ... if (((unsigned)num_items >= MAX_ALLOCATION) || ((unsigned)size >= MAX_ALLOCATION) ||
    • ((long long)size * num_items >= (long long) MAX_ALLOCATION)) { fprintf(stderr, "*** malloc_zone_calloc[%d]: arguments too large: %d,%dn", getpid(), (unsigned)num_items, (unsigned)size); return NULL; } ptr = zone->calloc(zone, num_items, size); ... return ptr;}First, the functions code contains the check of accessible sizes of allocated memory which are strangefor the 64-bit system. Second, the generated diagnostic message is incorrect because if we ask toallocate memory for 4 400 000 000 items, we will see a strange message saying that the program cannotallocate memory for (only) 105 032 704 items. This happens because of the explicit type conversion tothe unsigned type.Example 9. Virtual functionsOne of the nice examples of 64-bit errors is the use of wrong argument types in definitions of virtualfunctions. Usually it is not ones mistake but just an "accident". It is nobodys fault but the error stillremains. Consider the following case.For a very long time there has been the CWinApp class in the MFC library that has the WinHelp function:class CWinApp { ... virtual void WinHelp(DWORD dwData, UINT nCmd);};To show the programs own help in a user application you had to overrid this function:class CSampleApp : public CWinApp { ... virtual void WinHelp(DWORD dwData, UINT nCmd);};
    • Everything was alright until 64-bit systems appeared. The MFC developers had to change the interfaceof the WinHelp function (and some other functions as well) in the following way:class CWinApp { ... virtual void WinHelp(DWORD_PTR dwData, UINT nCmd);};The DWORD_PTR and DWORD types coincided in the 32-bit mode but they do not coincide in the 64-bitmode. Of course, the user applications developers must also change the type to DWORD_PTR but theyhave to learn about it somehow before doing this. As a result, an error occurs in the 64-bit version sincethe WinHelp function cannot be called in the user class (see Figure 9).
    • Figure 9 - The error related to virtual functionsExample 10. Magic constants as parametersMagic numbers contained in bodies of programs provoke errors and using them is a bad style. Suchnumbers are, for instance, numbers 1024 and 768 that strictly define screen resolution. Within thescope of this article, we are interested in those magic numbers that might cause issues in a 64-bitapplication. The most widely used magic numbers dangerous for 64-bit programs are shown in the tablein Figure 10.Figure 10 - Magic numbers dangerous for 64-bit programs
    • Consider an example of working with the CreateFileMapping function taken from some CAD-system:HANDLE hFileMapping = CreateFileMapping( (HANDLE) 0xFFFFFFFF, NULL, PAGE_READWRITE, dwMaximumSizeHigh, dwMaximumSizeLow, name);Number 0xFFFFFFFF is used instead of the correct reserved constant INVALID_HANDLE_VALUE. It isincorrect from the viewpoint of a Win64-program where the INVALID_HANDLE_VALUE constant takesvalue 0xFFFFFFFFFFFFFFFF. Here is a correct way of calling the function:HANDLE hFileMapping = CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, dwMaximumSizeHigh, dwMaximumSizeLow, name);Note. Some people think that value 0xFFFFFFFF turns into 0xFFFFFFFFFFFFFFFF while extending to thepointer. It is not so. According to C/C++ rules, value 0xFFFFFFFF has the "unsigned int" type since itcannot be represented with the "int" type. Correspondingly, value 0xFFFFFFFFu turns into0x00000000FFFFFFFFu when extending to the 64-bit type. But if you write (size_t)(-1), you will get theexpected 0xFFFFFFFFFFFFFFFF. Here "int" extends to "ptrdiff_t" first and then turns into "size_t".Example 11. Magic constants denoting sizeAnother frequent error is using magic constants to define an objects size. Consider an example of bufferallocation and zeroing:size_t count = 500;size_t *values = new size_t[count];// Only a part of the buffer will be filledmemset(values, 0, count * 4);In this case, in the 64-bit system, the amount of memory being allocated is larger than the amount ofmemory which is filled with zero values then (see Figure 11) . The error lies in the assumption that thesize of the size_t type is always four bytes.
    • Figure 11 - Only a part of the array is filledThis is the correct code:
    • size_t count = 500;size_t *values = new size_t[count];memset(values, 0, count * sizeof(values[0]));You may encounter similar errors when calculating sizes of memory being allocated or data serialization.Example 12. Stack overflowIn many cases, a 64-bit program consumes more memory and stack. Allocation of more physicalmemory is not dangerous since a 64-bit program can access much larger amounts of this type ofmemory than a 32-bit one. But increase of stack memory consumption might cause a stack overflow.The mechanism of using the stack differs in various operating systems and compilers. We will considerthe specifics of using the stack in the code of Win64 applications built with the Visual C++ compiler.When developing calling conventions in Win64 systems, the developers decided to bring an end todifferent versions of function calls. In Win32, there were a lot of calling conventions: stdcall, cdecl,fastcall, thiscall and so on. In Win64, there is only one "native" calling convention. The compiler ignoresmodifiers like __cdecl.The calling convention on the x86-64 platform resembles the fastcall convention in x86. In the x64-convention, the first four integer arguments (left to right) are passed in 64-bit registers used specially forthis purpose:RCX: 1-st integer argumentRDX: 2-nd integer argumentR8: 3-rd integer argumentR9: 4-th integer argumentAll the rest integer arguments are passed through the stack. The "this" pointer is considered an integerargument so it is always put into the RCX register. If floating-point values are passed, the first four ofthem are passed in the XMM0-XMM3 registers and all the next are passed through the stack.Although arguments may be passed in registers, the compiler will still reserve space for them in stacktherefore reducing the value of the RSP register (stack pointer). Each function must reserve at least 32bytes (four 64-bit values corresponding to the registers RCX, RDX, R8, R9) in the stack. This space in thestack lets you easily save the contents of registers passed into the function in the stack. The functionbeing called is not required to drop input parameters passed through the registers into the stack butstack space reservation allows to do this if necessary. If more than four integer parameters are passed,the corresponding additional space is reserved in the stack.The described feature leads to a significant growth of stack consumption speed. Even if the functiondoes not have parameters, 32 bytes will be "bit off" the stack all the same and they will not be usedanyhow then. The use of such a wasteful mechanism is determined by the purposes of unification anddebugging simplification.
    • Consider one more thing. The stack pointer RSP must be aligned on a 16-byte boundary before the nextcall of the function. Thus, the total size of the stack being used when calling a function withoutparameters in 64-bit code is 48 bytes: 8 (return address) + 8 (alignment) + 32 (reserved space forarguments).Can everything be so bad? No. Do not forget that a larger number of registers available to the 64-bitcompiler allows it to build a more effective code and avoid reserving stack memory for some localfunction variables. Thus, the 64-bit version of a function in some cases uses less stack memory than its32-bit version. To learn more about this question, see the article "The reasons why 64-bit programsrequire more stack memory".It is impossible to predict if a 64-bit program will consume more or less stack memory. Since a Win64-program can use 2-3 times more stack memory, you should secure yourself and change the projectoption responsible for the size of stack being reserved. Choose the Stack Reserve Size (/STACK:reserveswitch) parameter in the project settings and increase the size of stack being reserved three times. Thissize is 1 Mbyte by default.Example 13. A function with a variable number of arguments and bufferoverflowAlthough it is considered a bad style in C++ to use functions with a variable number of arguments suchas printf and scanf, they are still widely used. These functions provoke a lot of problems while portingapplications to other systems including 64-bit ones. Consider an example:int x;char buf[9];sprintf(buf, "%p", &x);The author of this code did not take into account that the pointers size might become larger than 32bits in future. As a result, this code will cause a buffer overflow on the 64-bit architecture (see Figure12). This error might be referred to the type of errors caused by magic numbers (number 9 in this case)but the buffer overflow can occur without magic numbers in a real application.
    • Figure 12 - A buffer overflow when working with the sprintf functionThere are several ways to correct this code. The most reasonable one is to factor the code in order toget rid of dangerous functions. For example, you may replace printf with cout and sprintf withboost::format or std::stringstream.Note. Linux-developers often criticize this recommendation arguing that gcc checks if the format stringcorresponds to actual parameters which are being passed, for instance, into the printf function.Therefore it is safe to use the printf function. But they forget that the format string can be passed fromsome other part of the program or loaded from resources. In other words, in a real program, the formatstring is seldom present explicitly in the code and therefore the compiler cannot check it. But if thedeveloper uses Visual Studio 2005/2008/2010, he will not get a warning on the code like "void *p = 0;printf("%x", p);" even if he uses the /W4 and /Wall switches.Example 14. A function with a variable number of arguments and wrongformatYou may often see incorrect format strings in programs when working with the printf function and othersimilar functions. Because of these you will get wrong output values. Although it will not cause a crash, itis certainly an error:const char *invalidFormat = "%u";size_t value = SIZE_MAX;// A wrong value will be printedprintf(invalidFormat, value);In other cases, an error in the format string will be crucial. Consider an example based on animplementation of the UNDO/REDO subsystem in one program:// The pointers were saved as strings hereint *p1, *p2;....
    • char str[128];sprintf(str, "%X %X", p1, p2);// In another function this string// was processed in the following way:void foo(char *str){ int *p1, *p2; sscanf(str, "%X %X", &p1, &p2); // The result is incorrect values of p1 and p2 pointers. ...}The "%X" format is not intended to work with pointers and therefore such code is incorrect from theviewpoint of 64-bit systems. In 32-bit systems, it is quite efficient yet looks ugly.Example 15. Storing integer values in doubleWe did not encounter this error ourselves. Perhaps it is rare yet quite possible.The double type has the size 64 bits and it is compatible with the IEEE-754 standard on 32-bit and 64-bitsystems. Some programmers use the double type to store and handle integer types:size_t a = size_t(-1);double b = a;--a;--b;size_t c = b; // x86: a == c // x64: a != cThe code of this example can be justified in case of a 32-bit system since the double type has 52significant bits and can store a 32-bit integer values without loss. But when you try to store a 64-bitinteger value into double, you might lose an exact value (see Figure 13).
    • Figure 13 - The number of significant bits in the types size_t and doubleExample 16. Address arithmetic. A + B != A - (-B)Address arithmetic is a means of calculating an address of some object with the help of arithmeticoperations over pointers and also using pointers in comparison operations. Address arithmetic is alsocalled pointer arithmetic.It is address arithmetic that many 64-bit errors refer to. Errors often occur in expressions where pointersand 32-bit variables are used together.Consider the first error of this type:char *A = "123456789";unsigned B = 1;char *X = A + B;char *Y = A - (-B);if (X != Y) cout << "Error" << endl;The reason why A + B == A - (-B) in a Win32 program is explained in Figure 14.Figure 14 - Win32: A + B == A - (-B)The reason why A + B != A - (-B) in a Win64 program is explained in Figure 15.
    • Figure 15 - Win64: A + B != A - (-B)You can eliminate the error if you use an appropriate memsize-type. In this case, the ptrdfiff_t type isused:char *A = "123456789";ptrdiff_t B = 1;char *X = A + B;char *Y = A - (-B);Example 17. Address arithmetic. Signed and unsigned types.Consider one more kind of the error related to signed and unsigned types. In this case, the error willimmediately cause a program crash instead of a wrong comparison operation.LONG p1[100];ULONG x = 5;LONG y = -1;LONG *p2 = p1 + 50;p2 = p2 + x * y;*p2 = 1; // Access violationThe "x * y" expression has value 0xFFFFFFFB and its type is unsigned. This code is efficient in the 32-bitversion since addition of the pointer to 0xFFFFFFFB is equivalent to its decrement by 5. In the 64-bitversion, the pointer will point far outside the p1 arrays boundaries after being added to 0xFFFFFFFB(see Figure 16).
    • Figure 16 - Out of the arrays boundaries
    • To correct this issue, you should use memsize-types and be careful when working with signed andunsigned types:LONG p1[100];LONG_PTR x = 5;LONG_PTR y = -1;LONG *p2 = p1 + 50;p2 = p2 + x * y;*p2 = 1; // OKExample 18. Address arithmetic. Overflows.class Region { float *array; int Width, Height, Depth; float Region::GetCell(int x, int y, int z) const; ...};float Region::GetCell(int x, int y, int z) const { return array[x + y * Width + z * Width * Height];}This code is taken from a real application of mathematic modeling where the size of physical memory isa very crucial resource, so the possibility to use more than 4 Gbytes of memory on the 64-bitarchitecture significantly increases the computational power. In programs of this class, one-dimensionalarrays are often used in order to save memory, and they are handled like third-dimensional arrays. Todo this, there exist functions similar to GetCell that provide access to necessary items.This code works correctly with pointers if the result of the " x + y * Width + z * Width * Height"expression does not exceed INT_MAX (2147483647). Otherwise an overflow will occur leading to anunexpected program behavior.This code could always work correctly on the 32-bit platform. Within the scope of the 32-bitarchitecture, the program cannot get the necessary memory amount to create an array of such a size.But this limitation is absent on the 64-bit architecture and the arrays size might easily exceed INT_MAXitems.Programmers often make a mistake trying to fix the code this way:float Region::GetCell(int x, int y, int z) const {
    • return array[static_cast<ptrdiff_t>(x) + y * Width + z * Width * Height];}They know that the expression to calculate the index will have the ptrdiff_t type according to C++ rulesand try to avoid the overflow therefore. But the overflow might occur inside the "y * Width" or "z *Width * Height" subexpressions since it is still the int type that is used to calculate them.If you want to fix the code without changing the types of the variables participating in the expression,you may explicitly convert each subexpression to the ptrdiff_t type:float Region::GetCell(int x, int y, int z) const { return array[ptrdiff_t(x) + ptrdiff_t(y) * Width + ptrdiff_t(z) * Width * Height];}Another, better, solution is to change the variables types:typedef ptrdiff_t TCoord;class Region { float *array; TCoord Width, Height, Depth; float Region::GetCell(TCoord x, TCoord y, TCoord z) const; ...};float Region::GetCell(TCoord x, TCoord y, TCoord z) const { return array[x + y * Width + z * Width * Height];}Example 19. Changing an arrays typeSometimes programmers change the type of an array while processing it for the purpose ofconvenience. The following code contains dangerous and safe type conversions:int array[4] = { 1, 2, 3, 4 };enum ENumbers { ZERO, ONE, TWO, THREE, FOUR };
    • //safe cast (for MSVC)ENumbers *enumPtr = (ENumbers *)(array);cout << enumPtr[1] << " ";//unsafe castsize_t *sizetPtr = (size_t *)(array);cout << sizetPtr[1] << endl;//Output on 32-bit system: 2 2//Output on 64-bit system: 2 17179869187As you may see, the output results differ in the 32-bit and 64-bit versions. On the 32-bit system, theaccess to the arrays items is correct because the sizes of the size_t and int types coincide and we getthe output "2 2".On the 64-bit system, we got "2 17179869187" in the output since it is this very value 17179869187which is located in the first item of the sizePtr array (see Figure 17). Sometimes this behavior is intendedbut most often it is an error.
    • Figure 17 - Representation of array items in memoryNote. The size of the enum type by default coincides with the size of the int type in the Visual C++compiler, i.e. the enum type is a 32-bit type. You can use enum of a different size only with the help of anextension which is considered non-standard in Visual C++. That is why the given example is correct inVisual C++ but from the viewpoint of other compilers conversion of an int-item pointer to an enum-itempointer is also incorrect.Example 20. Wrapping a pointer in a 32-bit typeSometimes pointers are stored in integer types. Usually the int type is used for this purpose. This isperhaps one of the most frequent 64-bit errors.char *ptr = ...;int n = (int) ptr;...ptr = (char *) n;In a 64-bit program, this is incorrect since the int type remains 32-bit and cannot store a 64-bit pointer.The programmer often cannot notice it at once. Due to mere luck, the pointer might always refer toobjects located within the first 4 Gbytes of the address space during the testing. In this case, the 64-bitprogram will work efficiently and crash only in a large period of time (see Figure 18).
    • Figure 18 - Putting a pointer into a variable of int typeIf you still need to store a pointer in a variable of an integer type, you should use such types as intptr_t,uintptr_t, ptrdiff_t and size_t.
    • Example 21. Memsize-types in unionsWhen you need to work with a pointer as an integer, it is sometimes convenient to use a union asshown in the example and work with the numeric representation of the type without explicitconversions:union PtrNumUnion { char *m_p; unsigned m_n;} u;u.m_p = str;u.m_n += delta;This code is correct on 32-bit systems and incorrect on 64-bit ones. Changing the m_n member on a 64-bit system, we work only with a part of the m_p pointer (see Figure 19).Figure 19 - Representation of a union in memory on a 32-bit system and 64-bit systems.You should use a type that would correspond to the pointers size:union PtrNumUnion { char *m_p; uintptr_t m_n; //type fixed} u;Example 22. An infinity loopMixed use of 32-bit and 64-bit types can unexpectedly cause infinity loops. Consider a synthetic sampleillustrating a whole class of such defects:size_t Count = BigValue;for (unsigned Index = 0; Index != Count; Index++){ ... }
    • This loop will never stop if the Count value > UINT_MAX. Assume that this code worked with thenumber of iterations less than UINT_MAX on 32-bit systems. But the 64-bit version of this program canprocess more data and it may require more iterations. Since the values of the Index variable lie withinthe range [0..UINT_MAX], the condition "Index != Count" will never be fulfilled and it will cause aninfinity loop (see Figure 20).
    • Figure 20 - The mechanism of an infinity loopExample 23. Bit operations and NOT operationBit operations require special care from the programmer when developing crossplatform applicationswhere data types may have different sizes. Since migration of a program to the 64-bit platform alsomakes capacity of some types change, it is highly probable that errors will occur in those code fragmentsthat work with separate bits. Most often it happens when 32-bit and 64-bit data types are handledtogether. Consider an error occurring in the code because of an incorrect use of the NOT operation:UINT_PTR a = ~UINT_PTR(0);ULONG b = 0x10;UINT_PTR c = a & ~(b - 1);c = c | 0xFu;if (a != c)
    • cout << "Error" << endl;The error consists in that the mask defined by the "~(b - 1)" expression has the ULONG type. It causeszeroing of the most significant bits of the "a" variable although it is only the four least significant bitsthat should have been zeroed (see Figure 21).
    • Figure 21 - The error occurring because of zeroing of the most significant bitsThe correct version of the code looks as follows:UINT_PTR c = a & ~(UINT_PTR(b) - 1);This example is extremely simple but it is very good to demonstrate the class of errors that might occurwhen you actively work with bit operations.Example 24. Bit operations, offsetsptrdiff_t SetBitN(ptrdiff_t value, unsigned bitNum) { ptrdiff_t mask = 1 << bitNum; return value | mask;}
    • This code works well on the 32-bit architecture and allows to set a bit with the numbers from 0 to 31into one. After porting the program to the 64-bit platform, you need to set bits with the numbers from 0to 63. But this code cannot set the most significant bits with the numbers 32-63. Note that the numericliteral "1" has the int type and an overflow will occur after an offset at 32 positions as shown in Figure22. We will get 0 (Figure 22-B) or 1 (Figure 22-C) - it depends upon the compilers implementation.Figure 22 - a) correct setting of the 31st bit in the 32-bit code (the bits are counted beginning with 0);b,c) - The error of setting the 32nd bit on the 64-bit system (the two variants of behavior that dependupon the compiler)To correct the code, you should make the "1" constants type the same as the type of the mask variable:ptrdiff_t mask = static_cast<ptrdiff_t>(1) << bitNum;
    • Note also that the incorrect code will lead to one more interesting error. When setting the 31-st bit onthe 64-bit system, the result of the function is 0xffffffff80000000 (see Figure 23). The result of the 1 <<31 expression is the negative number -2147483648. This number is represented in a 64-bit integervariable as 0xffffffff80000000.Figure 23 - The error of setting the 31-st bit on the 64-bit systemExample 25. Bit operations and sign extensionThe error shown below is rare yet, unfortunately, quite difficult to understand. So lets discuss it indetail.struct BitFieldStruct { unsigned short a:15; unsigned short b:13;};BitFieldStruct obj;obj.a = 0x4000;size_t x = obj.a << 17; //Sign Extensionprintf("x 0x%Ixn", x);//Output on 32-bit system: 0x80000000//Output on 64-bit system: 0xffffffff80000000In the 32-bit environment, the sequence of expression calculation looks as shown in Figure 24.
    • Figure 24 - Calculation of the expression in the 32-bit codeNote that sign extension of the unsigned short type to int takes place during the calculation of the "obj.a<< 17" expression. The following code makes it clearer:#include <stdio.h>template <typename T> void PrintType(T){ printf("type is %s %d-bitn", (T)-1 < 0 ? "signed" : "unsigned", sizeof(T)*8);}struct BitFieldStruct { unsigned short a:15; unsigned short b:13;};int main(void){ BitFieldStruct bf; PrintType( bf.a ); PrintType( bf.a << 2); return 0;}
    • Result:type is unsigned 16-bittype is signed 32-bitNow lets see the consequence of a sign extension in 64-bit code. The sequence of expressioncalculation is shown in Figure 25.Figure 25 - Calculation of the expression in 64-bit codeThe member of the obj.a structure is cast from the bit field of the unsigned short type into int. The"obj.a << 17" expression has the int type but it is cast to ptrdiff_t and then to size_t before beingassigned to the addr variable. As a result, we will get value 0xffffffff80000000 instead of0x0000000080000000 we have expected.Be careful when working with bit fields. To avoid the described situation in our example, you just needto convert obj.a to the size_t type....size_t x = static_cast<size_t>(obj.a) << 17; // OKprintf("x 0x%Ixn", x);//Output on 32-bit system: 0x80000000//Output on 64-bit system: 0x80000000Example 26. Serialization and data exchangeSuccession to the existing communications protocols is an important element in migration of a softwaresolution to a new platform. You must provide the possibility of reading existing project formats, dataexchange between 32-bit and 64-bit processes and so on.
    • In general, the errors of this kind consist in serialization of memsize-types and data exchange operationsthat use them.:size_t PixelsCount;fread(&PixelsCount, sizeof(PixelsCount), 1, inFile);You cannot use types that change their size depending upon the development environment in binarydata exchange interfaces. In C++, most types do not have strict sizes and therefore they all cannot beused for these purposes. That is why the developers of development tools and programmers themselvescreate data types that have strict sizes such as __int8, __int16, INT32, word64, etc.Even on correcting all the issues referring to type sizes, you might encounter the problem ofincompatibility of binary formats. The reason lies in a different data representation. Most often it isdetermined by a different byte order.Byte order is a method of writing bytes of multi-byte numbers (see Figure 26). The little-endian ordermeans that writing begins with the least significant byte and ends with the most significant byte. Thiswriting order is accepted in the memory of personal computers with x86 and x86-64-processores. Thebig-endian order means that writing begins with the most significant byte and ends with the leastsignificant byte. This order is a standard for TCP/IP protocols. That is why the big-endian byte order isoften called the network byte order. This byte order is used in processors Motorola 68000 and SPARC.By the way, some processors can work in both orders. For instance, IA-64 is such a processor.Figure 26 - Byte order in a 64-bit type in little-endian and big-endian systemsWhile developing a binary data interface or format, you should remember about the byte order. If the64-bit system you are porting your 32-bit application to has a different byte order, you will just have to
    • take this into account for your code. To convert between the big-endian and little-endian byte orders,you may use the functions htonl(), htons(), bswap_64, etc.Example 27. Changes in type alignmentBesides changes of sizes of some data types, errors might also due to changes of rules of their alignmentin a 64-bit system (see Figure 27).
    • Figure 27 - Sizes of types and their alignment boundaries (the figures are exact for Win32/Win64 butmay vary in the "Unix-world", so they are given only for demonstration purpose)Consider a description of the issue found in some forum:I have encountered an issue in Linux today. There is a data structure consisting of several fields: a 64-bitdouble, 8 unsigned char and one 32-bit int. All in all there are 20 bytes (8 + 8*1 + 4). On 32-bit systems,sizeof equals 20 and everything is ok. But on the 64-bit Linux, sizeof returns 24. That is, there is a 64-bitboundary alignment.Then this person discusses the problem of data compatibility and asks for advice how to pack the data inthe structure. We are not interested in this at the moment. What is relevant, this is another type oferrors that might occur when you port applications to 64-bit systems.
    • It is quite clear and familiar that changes of the sizes of fields in a structure cause the size of thestructure itself to change. But here we have a different case. The sizes of the fields remain the same butthe structures size still changes due to other alignment rules (see Figure 28). This behavior might lead tovarious errors, for instance, errors of format incompatibility of saved data.
    • Figure 28 - A scheme of structures and type alignment rulesExample 28. Type alignments and why you mustnt write sizeof(x) +sizeof(y)Sometimes programmers use structures with an array of a variable size at the end. Such a structure andthe mechanism of memory allocation for it might look as follows:struct MyPointersArray { DWORD m_n; PVOID m_arr[1];} object;...malloc( sizeof(DWORD) + 5 * sizeof(PVOID) );...This code is correct in the 32-bit version but fails in the 64-bit version.When allocating memory needed to store an object like MyPointersArray that contains 5 pointers, youshould consider that the beginning of the m_arr array will be aligned on an 8-byte boundary. Dataarrangement in memory on different systems (Win32/Win64) is shown in Figure 29.Figure 29 - Data arrangement in memory in 32-bit and 64-bit systemsThe correct calculation of the size looks in the following way:struct MyPointersArray { DWORD m_n; PVOID m_arr[1];
    • } object;...malloc( FIELD_OFFSET(struct MyPointersArray, m_arr) + 5 * sizeof(PVOID) );...In this code, we determine the offset of the last structures member and add this offset to its size. Theoffset of a structures or class member may be obtained with the help of the offsetof or FIELD_OFFSETmacros. You should always use these macros to obtain the offset in a structure without relying on yourassumptions about sizes of types and rules of their alignment.Example 29. Overloaded functionsWhen you recompile a program, some other overloaded function might start to be selected (see Figure30).Figure 30 - Choosing an overloaded function in a 32-bit system and 64-bit systemHere is an example of the problem:class MyStack {...public: void Push(__int32 &); void Push(__int64 &); void Pop(__int32 &); void Pop(__int64 &);} stack;
    • ptrdiff_t value_1;stack.Push(value_1);...int value_2;stack.Pop(value_2);The inaccurate programmer put and then chose from the stack values of different types (ptrdiff_t andint). Their sizes coincided on the 32-bit system and everything was alright. When the size of the ptrdiff_ttype changed in the 64-bit program, the number of bytes put in the stack became larger than thenumber of bytes that would be fetched from it then.Example 30. Errors in 32-bit units working in WoW64The last example covers errors in 32-bit programs that occur when they are executed in the 64-bitenvironment. 64-bit software systems will include 32-bit units for a long time and therefore we mustprovide for their correct work in the 64-bit environment. The WoW64 subsystem fulfills this task verywell by isolating a 32-bit application, so that almost all 32-bit applications work correctly. However,sometimes errors happen and they refer most often to the redirection mechanism when working withfiles and Windows register.For instance, when dealing with a system that consists of 32-bit and 64-bit units which interact witheach other, you should consider that they use different register representations. Thus, the following linestopped working in a 32-bit unit in one program:lRet = RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWAREODBCODBC.INIODBC Data Sources", 0, KEY_QUERY_VALUE, &hKey);To make this program friends with other 64-bit parts, you should insert the KEY_WOW64_64KEY switch:lRet = RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWAREODBCODBC.INIODBC Data Sources", 0, KEY_QUERY_VALUE | KEY_WOW64_64KEY, &hKey);SummaryThe method of static code analysis shows the best result in searching for the errors described in thearticle. As an example of such a tool that performs this kind of analysis, we can name the Viva64 toolincluded into the PVS-Studio package we are developing.The methods of static search of defects allow to detect defects relying on the source program code. Theprogram behavior is estimated at all the execution paths simultaneously. Because of this, static analysislets you find defects that occur only at non-standard execution paths with rare input data. This featuresupplements other testing methods and increases security of applications. Static analysis systems mightbe used in source code audit, for the purpose of systematic elimination of defects in existing programs;
    • they can integrate into the development process and automatically detect defects in the code beingcreated.References 1. Andrey Karpov, Evgeniy Ryzhkov. Lessons on development of 64-bit C/C++ applications. http://www.viva64.com/articles/x64-lessons/ 2. Andrey Karpov. About size_t and ptrdiff_t. http://www.viva64.com/art-1-2-710804781.html 3. Andrey Karpov, Evgeniy Ryzhkov. 20 issues of porting C++ code on the 64-bit platform. http://www.viva64.com/art-1-2-599168895.html 4. Evgeniy Ryzhkov. PVS-Studio Tutorial. http://www.viva64.com/art-4-2-747004748.html 5. Andrey Karpov. A 64-bit horse that can count. http://www.viva64.com/art-1-2-377673569.html