分类： C/C++
2009-09-23 10:28:17
Program errors occurring while porting C++ code from 32-bit platforms on 64-bit ones are observed. Examples of the incorrect code and the ways to correct it are given. Methods and means of the code analysis which allow to diagnose the errors discussed, are listed.
This article describes the process of porting a 32-bit application to systems. The article is written for programmers who use C++ but it may also be useful for all who face the problem of porting applications on other platforms. The authors of the article are experts in the field of porting applications to 64-bit systems and the developers of tool, which facilitates the search of errors in 64-bit applications.
One should understand that the new class of errors, which appear while developing 64-bit programs, is not just some new incorrect constructions among thousands of others. These are inevitable difficulties which the developers of any developing program will face. This article will help you to prepare for these difficulties and will show ways to overcome them. Besides advantages, any new technology (in programming and other spheres as well) carries some limitations and even problems of using this technology. The same situation can be observed in the sphere of 64-bit software developing. We all know that 64-bit software is the next step of the information technologies development. But in reality, only few programmers have faced the nuances of this sphere and developing 64-bit programs in particular.
We won't dwell on the advantages which the use of 64-bit architecture provides. There are a lot of publications devoted to this theme and the reader can find them easily.
The aim of this article is to observe thoroughly the problems, which can be faced by a developer of 64-bit programs. In this article you will learn about:
The given information will allow you to:
This article contains a lot of examples you should try in the programming environment for better understanding. Going into them will give you more than just a set of separate elements. You will open the door into the world of 64-bit systems.
To make the following text easier for understanding let's remember some types we can face. (see table N1).
| Type name | Type size (32-bit system) | Type size (64-bit system) | Description |
|---|---|---|---|
| ptrdiff_t | 32 | 64 | Signed integer type which appears after subtraction of two pointers. This type is used to keep memory sizes. Sometimes it is used as the result of function returning size or -1 if an error occurs. |
| size_t | 32 | 64 | Unsigned integer type. Data of this bype is returned by the sizeof() operator. This type is used to keep size or number of objects. |
| intptr_t, uintptr_t, SIZE_T, SSIZE_T, INT_PTR, DWORD_PTR, etc | 32 | 64 | Integer types capable to keep pointer value. |
| time_t | 32 | 64 | Amount of time in seconds. |
We'll use term "memsize" type in the text. This term means any simple integer type which is capable to keep a pointer and changes its size according to the change of the platform dimension form 32-bit to 64-bit. For example, memsize types are: size_t, ptrdiff_t, all pointers, intptr_t, INT_PTR, DWORD_PTR.
We should say some words about the data models which determine the correspondence of the sizes of fundamental types for different systems. Table N2 contains data models which can interest us.
| ILP32 | LP64 | LLP64 | ILP64 | |
|---|---|---|---|---|
| char | 8 | 8 | 8 | 8 |
| short | 16 | 16 | 16 | 16 |
| int | 32 | 32 | 32 | 64 |
| long | 32 | 64 | 32 | 64 |
| long long | 64 | 64 | 64 | 64 |
| size_t | 32 | 64 | 64 | 64 |
| pointer | 32 | 64 | 64 | 64 |
In this article we'll assume that the program will be ported from a system with the ILP32 data model to systems with or data model.
And finally, 64-bit model in Linux (LP64) differs from that in Windows (LLP64) only in the size of long type. Since it is their only difference, we'll avoid using long, unsigned'long types, and will use ptrdiff_t, size_t types to generalize the article.
Let us observe the type errors which occur while porting programs on the 64-bit architecture.
All books on high-quality code development recommend you set the level of warnings shown by compiler to the highest possible value. But there are situations in practice when the diagnosis level for some project parts is lower or the diagnosis is even disabled. As a rule it is very old code which is supported but not modified. Programmers who work over the project are used to the fact that this code works and don't take its quality into consideration. Thus, one can miss serious warnings produced by the compiler while porting programs on the new 64-bit system.
While porting an application you should obligatory turn on warnings for the entire project. This will help you check the compatibility of the code and analyze the code thoroughly. This approach can help you save a lot of time while debugging the project on the new architecture.
If we won't do this, we will face the simplest and stupidest errors in all their variety. Here is a simple example of overflow which occurs in a 64-bit program if we ignore warnings at all.
unsigned char *array[50]; unsigned char size = sizeof(array); 32-bit system: sizeof(array) = 200 64-bit system: sizeof(array) = 400 |
The typical example is the incorrect use of printf, scanf functions and their variants:
1) const char *invalidFormat = "%u"; size_t value = SIZE_MAX; printf(invalidFormat, value); |
2) char buf[9]; sprintf(buf, "%p", pointer); |
In the first case it is not taken into account that size_t type is not equivalent to unsigned type on the 64-bit platform. It will cause printing of an incorrect result if value > UINT_MAX.
In the second case the developer didn't take into account that the pointer size may become more than 32-bit in future. As the result this code will cause buffer overflow on the 64-bit architecture.
Incorrect use of functions with a variable number of arguments is a typical error on all the architectures, not only on the 64-bit one. This is related to the fundamental danger of the use of the given C++ language constructions. The common practice is to refuse them and use safe programming methods. We strongly recommend you modify the code and use safe methods. For example, you may replace printf with cout, and sprintf with boost::format or std::stringstream.
If you have to maintain a code which uses functions of sscanf type, in the control lines format we can use special macros which turn into necessary modifiers for different systems. For example:
// PR_SIZET on Win64 = "I" // PR_SIZET on Win32 = "" // PR_SIZET on Linux64 = "l" // ... size_t u; scanf("%" PR_SIZET "u", &u); |
Low-quality code often contains magic numbers, the mere presence of whose is dangerous. During the migration of the code on the 64-bit platform these magic numbers may make the code inefficient if they participate in calculation of address, objects size or bit operations.
Table N3 contains basic magic numbers which may influence the workability of an application on a new platform.
| Value | Description |
|---|---|
| 4 | Number of bytes in a pointer type |
| 32 | Number of bits in a pointer type |
| 0x7fffffff | The maximum value of a 32-bit signed variable. Mask for zeroing of the high bit in a 32-bit type. |
| 0x80000000 | The minimum value of a 32-bit signed variable. Mask for allocation of the high bit in a 32-bit type. |
| 0xffffffff | The maximum value of a 32-bit variable. An alternative record -1 as an error sign. |
You should study the code thoroughly in search of magic numbers and replace them with safe numbers and expressions. To do so you can use sizeof() operator, special values from
Let's take a look at some errors related to the use of magic numbers. The most frequent is using numbers to store type sizes.
1) size_t ArraySize = N * 4; intptr_t *Array = (intptr_t *)malloc(ArraySize); |
2) size_t values[ARRAY_SIZE]; memset(values, ARRAY_SIZE * 4, 0); |
3) size_t n, newexp; n = n >> (32 - newexp); |
Let's assume that in all cases the size of the types used is always 4 bytes. To make the code correct, we should use the sizeof() operator.
1) size_t ArraySize = N * sizeof(intptr_t);
intptr_t *Array = (intptr_t *)malloc(ArraySize);
|
2) size_t values[ARRAY_SIZE];
memset(values, ARRAY_SIZE * sizeof(size_t), 0);
|
or
memset(values, sizeof(values), 0); //preferred alternative |
3) size_t n, newexp;
n = n >> (CHAR_BIT * sizeof(n) - newexp);
|
Sometimes we may need a specific number. As an example let's take the size_t where all the bits except 4 low bits must be filled with ones. In a 32-bit program this number may be declared in the following way.
// constant '1111..110000' const size_t M = 0xFFFFFFF0u; |
This code is incorrect for a 64-bit system. Such errors are very unpleasant because the record of magic numbers may be carried out in different ways and the search for them is very laborious. Unfortunately, there is no other way except to find and to correct this code using #ifdef or a special macro.
#ifdef _WIN64 #define CONST3264(a) (a##i64) #else #define CONST3264(a) (a) #endif const size_t M = ~CONST3264(0xFu); |
Sometimes as an error code or other special marker "-1" value is used which is written as "0xffffffff". On the 64-bit platform the recorded expression is incorrect and we should use the "-1" value explicitly. Here is an example of an incorrect code using 0xffffffff value as an error sign.
#define INVALID_RESULT (0xFFFFFFFFu) size_t MyStrLen(const char *str) { if (str == NULL) return INVALID_RESULT; ... return n; } size_t len = MyStrLen(str); if (len == (size_t)(-1)) ShowError(); |
To be on the safe side, let's make sure that you know clearly what the result of "(size_t)(-1)" value is on the 64-bit platform. You may make a mistake saying value 0x00000000FFFFFFFFu. According to C++ rules -1 value turns into a signed equivalent of a higher type and then into an unsigned value:
int a = -1; // 0xFFFFFFFFi32 ptrdiff_t b = a; // 0xFFFFFFFFFFFFFFFFi64 size_t c = size_t(b); // 0xFFFFFFFFFFFFFFFFui64 |
Thus "(size_t)(-1)" on the 64-bit architecture is represented by 0xFFFFFFFFFFFFFFFFui64 value which is the highest value for the 64-bit size_t type.
Let's return to the error with INVALID_RESULT. The use of the number 0xFFFFFFFFu causes execution failure of "len == (size_t)(-1)" condition in a 64-bit program. The best solution is to change the code in such a way that it doesn't need special marker values. If you need to use them for some reason or consider this suggestion unreasonable, to correct the code fundamentally just use fair value -1.
#define INVALID_RESULT (size_t(-1))
...
|
Double type as a rule has 64 bits size and is compatible with IEEE-754 standard on 32-bit and 64-bit systems. Some programmers use double type for storing of and work with integer types.
size_t a = size_t(-1); double b = a; --a; --b; size_t c = b; // x86: a == c // x64: a != c |
The given example can be justified on a 32-bit system for double type has 52 significant bits and is capable to store a 32-bit integer value without a loss. But while trying to store a 64-bit integer in double the exact value can be lost (see picture 1).
It is possible that an approximate value can be used in your program, but to be on the safe side we'd like to warn you about possible effects on the new architecture. And in any case it is not recommended to mix integer arithmetic with floating-point arithmetic.
Bit shifting operations can cause a lot of problems during the port from the 32-bit system on a 64-bit one if used inattentively. Let's begin with an example of a function which defines the bit you've chosen as 1 in a variable of memsize type.
ptrdiff_t SetBitN(ptrdiff_t value, unsigned bitNum) { ptrdiff_t mask = 1 << bitNum; return value | mask; } |
The given code works only on the 32-bit architecture and allows to define bits with numbers from 0 to 31. After the program is ported port on a 64-bit platform it becomes necessary to define bits from 0 to 63. What value will the SetBitN(0, 32) call return? If you think that the value is 0x100000000, the author is glad because he hasn't prepared this article in vain. You'll get 0.
Pay attention that "1" has int type and during the shift on 32 positions an overflow will occur as it is shown on picture 2.
To correct the code it is necessary to make the constant "1" of the same type as the variable mask.
ptrdiff_t mask = ptrdiff_t(1) << bitNum; |
or
ptrdiff_t mask = CONST3264(1) << bitNum; |
One more question. What will be the result of the uncorrected function SetBitN(0, 31) call? The right answer is 0xffffffff80000000. The result of 1 << 31 expression is negative number -2147483648. This number is formed in a 64-bit integer variable as 0xffffffff80000000. You should keep in mind and take into consideration the effects of the shift of values of different types. To make you understand the stated information better table N4 contains interesting expressions with shifts on the 64-bit system.
| Expression | Result (Dec) | Result (Hex) |
|---|---|---|
| ptrdiff_t Result; Result = 1 << 31; | -2147483648 | 0xffffffff80000000 |
| Result = ptrdiff_t(1) << 31; | 2147483648 | 0x0000000080000000 |
| Result = 1U << 31; | 2147483648 | 0x0000000080000000 |
| Result = 1 << 32; | 0 | 0x0000000000000000 |
| Result = ptrdiff_t(1) << 32; | 4294967296 | 0x0000000100000000 |
Many errors during the migration on 64-bit systems are related to the change of a pointer size in relation to the size of usual integers. Usual integers and pointers have the same size in an environment with the ILP32 data model. Unfortunately, the 32-bit code is based on this supposition everywhere. Pointers are often casted to int, unsigned int and other types improper to fulfill address calculations.
One should use only memsize types for integer form of pointers. The uintptr_t type is more preferable since it shows programmer's intentions more clearly and makes the code more portable saving it from future changes
Let's take a look at two small examples.
1) char *p; p = (char *) ((int)p & PAGEOFFSET); |
2) DWORD tmp = (DWORD)malloc(ArraySize); ... int *ptr = (int *)tmp; |
Both examples do not take into account that the pointer size may differ from 32-bits. They use explicit type conversion which truncates high bits in the pointer and this is an error on the 64-bit system. Here are the corrected versions which use integer memsize types intptr_t and DWORD_PTR to store pointer addresses:
1) char *p; p = (char *) ((intptr_t)p & PAGEOFFSET); |
2) DWORD_PTR tmp = (DWORD_PTR)malloc(ArraySize); ... int *ptr = (int *)tmp; |
The two examples studied are dangerous because the program failure may be found much later. The program may work absolutely correctly with a small data on a 64-bit system while the truncated addresses are located in the first 4 Gb of memory. And then on launching the program for large production aims there will be the memory allocation out of first 4 Gb. The code given in the examples will cause an undefined behavior of the program on the object out of first 4 Gb while processing the pointer.
The following code won't hide and will show up at the first execution.
void GetBufferAddr(void **retPtr) { ... // Access violation on 64-bit system *retPtr = p; } unsigned bufAddress; GetBufferAddr((void **)&bufAddress); |
The correction is also in the choice of the type capable to store the pointer.
uintptr_t bufAddress; GetBufferAddr((void **)&bufAddress); //OK |
There are situations when storing of a pointer address into a 32-bit type is just necessary. Mostly such situations appear when it is necessary to work with old API functions. For such cases one should resort to special functions LongToIntPtr, PtrToUlong etc.
In the end I'd like to mention that it will be a bad style to store a pointer address into types which are always equal to 64-bits. One will have to correct the code shown further again when 128-bit systems will appear.
PVOID p; // Bad style. The 128-bit time will come. __int64 n = __int64(p); p = PVOID(n); |
The peculiarity of a union is that for all members of the union the same memory area is allocated that is, they overlap. Although the access to this memory area is possible with the use of any of the elements the element for this aim should be chosen so that the result won't be meaningless.
One should pay attention to the unions which contain pointers and other members of memsize type.
When there is a necessity to work with a pointer as an integer sometimes it is convenient to use the union as it is shown in the example, and work with the numeric form of the type without using explicit conversions.
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 is incorrect on 64-bit ones. When changing the m_n member on a 64-bit system we work only with a part of the m_p. We should use the type which will correspond to the pointer size.
union PtrNumUnion { char *m_p; size_t m_n; //type fixed } u; |
Another frequent use of the union is the presentation of one member as a set of other smaller ones. For example, we may need to split a value of size_t type into bytes to carry out the table algorithm of calculation of the number of zero bits in a byte.
union SizetToBytesUnion { size_t value; struct { unsigned char b0, b1, b2, b3; } bytes; } u; SizetToBytesUnion u; u.value = value; size_t zeroBitsN = TranslateTable[u.bytes.b0] + TranslateTable[u.bytes.b1] + TranslateTable[u.bytes.b2] + TranslateTable[u.bytes.b3]; |
Here is a fundamental algorithmic error which consists in the supposition that size_t type consists of 4 bytes. The possibility of the automatic search of algorithmic errors is hardly possible but we can provide the search of all the unions and check the presence of memsize types in them. Having found such a union we can find an algorithmic error and rewrite the code in the following way.
union SizetToBytesUnion { size_t value; unsigned char bytes[sizeof(value)]; } u; SizetToBytesUnion u; u.value = value; size_t zeroBitsN = 0; for (size_t i = 0; i != sizeof(bytes); ++i) zeroBitsN += TranslateTable[bytes[i]]; |
Sometimes it is necessary (or just convenient) to present array items as elements of a different type. Dangerous and safe type conversions are shown in the following code.
int array[4] = { 1, 2, 3, 4 }; enum ENumbers { ZERO, ONE, TWO, THREE, FOUR }; //safe cast (for MSVC2005) ENumbers *enumPtr = (ENumbers *)(array); cout << enumPtr[1] << " "; //unsafe cast size_t *sizetPtr = (size_t *)(array); cout << sizetPtr[1] << endl; //Output on 32-bit system: 2 2 //Output on 64 bit system: 2 17179869187 |
As you can see the program output is different in 32-bit and 64-bit systems. On the 32-bit system the access to the array items is fulfilled correctly because sizes of size_t and int coincide and we see "2 2".
On a 64-bit system we got "2 17179869187" in the output because the 17179869187 value is located in the first item of sizetPtr array (see picture 3). In some cases we need this very behavior but usually it is an error.
The fix of the described situation is rejecting dangerous type conversions by modernizing the program. Another variant is to create a new array and copy values of the original one into it.
If there are big derived class graphs with virtual functions in your program, there is a risk to use arguments of different types inattentively. However, these types actually coincide on the 32-bit system. For example, in the base class you use size_t type as an argument of a virtual function and in the derived class you use the unsigned type. So, this code will be incorrect on a 64-bit system.
But an error like this doesn't necessarily hide in big derived class graphs and here is one of the examples.
class CWinApp { ... virtual void WinHelp(DWORD_PTR dwData, UINT nCmd); }; class CSampleApp : public CWinApp { ... virtual void WinHelp(DWORD dwData, UINT nCmd); }; |
Let's follow the life-cycle of the development of some applications. Imagine that first it was being developed for Microsoft Visual C++ 6.0 when WinHelp function in CWinApp class had the following prototype:
virtual void WinHelp(DWORD dwData, UINT nCmd = HELP_CONTEXT); |
It was absolutely correct to carry out an overlap of the virtual function in CSampleApp class as it is shown in the example. Then the project was ported into Microsoft Visual C++ 2005 where the function prototype in CWinApp class had undergone some changes which consisted in the replacement of DWORD type with DWORD_PTR type. On the 32-bit system the program will work absolutely correctly since DWORD and DWORD_PTR types coincide. Troubles will appear during the compilation of the given code for a 64-bit platform. We'll get two functions with the same name but different parameters and as a result the user's code won't be executed.
The correction is in the use of the same types in the corresponding virtual functions.
class CSampleApp : public CWinApp { ... virtual void WinHelp(DWORD_PTR dwData, UINT nCmd); }; |
An important point during the port of a software solution on a new platform is succession to the existing data exchange protocol. It is necessary to read existing projects formats, to carry out the data exchange between 32-bit and 64-bit processes, etc.
Mostly the errors of this kind are in the serialization of memsize types and data exchange operations using them.
1) size_t PixelCount;
fread(&PixelCount, sizeof(PixelCount), 1, inFile);
|
2) __int32 value_1;
SSIZE_T value_2;
inputStream >> value_1 >> value_2;
|
3) time_t time;
PackToBuffer(MemoryBuf, &time, sizeof(time));
|
In all the given examples there are errors of two kinds: the use of types of volatile size in binary interfaces and ignoring the byte order.
It is unacceptable to use types which change their size depending on the development environment in binary interfaces of data exchange. In C++ language all the types don't have distinct sizes and consequently it is not possible to use them all for these purposes. That's why the developers of the development environments and programmers themselves create data types which have an exact size such as __int8, __int16, INT32, word64 etc.
The usage of such types provides data portability between programs on different platforms although it needs the usage of odd ones. The three shown examples are written inaccurately and this will show up on the changing of the capacity of some data types from 32-bit to 64-bit. Taking into account the necessity to support old data formats the correction may look as follows:
1) size_t PixelCount; __uint32 tmp; fread(&tmp, sizeof(tmp), 1, inFile); PixelCount = static_cast |
2) __int32 value_1; __int32 value_2; inputStream >> value_1 >> value_2; |
3) time_t time; __uint32 tmp = static_cast<__uint32>(time); PackToBuffer(MemoryBuf, &tmp, sizeof(tmp)); |
But the given version of correction cannot be the best. During the port on the 64-bit system the program may process a large number of data and the use of 32-bit types in the data may become a serious problem. In this case we may leave the old code for compatibility with the old data format having corrected the incorrect types, and fulfill the new binary data format taking into account the errors made. One more variant is to refuse binary formats and take text format or other formats provided by various libraries.
Even after the correction of volatile type sizes you may face the incompatibility of binary formats. The reason is different data presentation. Most frequently it is related to a different byte order.
The byte order is a method of recording of bytes of multibyte numbers (see also picture 4). The little-endian order means that the recording starts with the lowest byte and ends with the highest one. This recording order was acceptable for memory of PCs with x86-processors. The big-endian order - the recording starts with the highest byte and ends with the lowest one. This order is a standard for TCP/IP protocols. That's why the big-endian byte order is often called the network byte order. This byte order is used by the Motorola 68000, SPARC processors.
While developing the binary interface or data format you should keep the byte order in mind. If the 64-bit system on which you are porting a 32-bit application has a different byte order you'll just have to take it into account in your code. For conversion between the big-endian and the little-endian byte orders you may use functions htonl(), htons(), bswap_64, etc.
If you use bit fields you should keep in mind that the use of memsize types will cause the change of sizes of structures and alignment. For example, the structure shown further will have 4 bytes size on the 32-bit system and 8 bytes size on a 64-bit one.
struct MyStruct {
size_t r : 5;
};
|
But our attention to bit fields is not limited by that. Let's take a delicate example.
struct BitFieldStruct { unsigned short a:15; unsigned short b:13; }; BitFieldStruct obj; obj.a = 0x4000; size_t addr = obj.a << 17; //Sign Extension printf("addr 0x%Ix\n", addr); //Output on 32-bit system: 0x80000000 //Output on 64-bit system: 0xffffffff80000000 |
Pay attention that if you compile the example for a 64-bit system there is a sign extension in "addr = obj.a << 17;" expression, in spite of the fact that both variables, addr and obj.a, are unsigned. This sign extension is caused by the rules of type conversion which are used in the following way (see also picture 5):
Therefore you should be attentive while working with bit fields. To avoid the described effect in our example we can simply use explicit conversion from obj.a type to size_t type.
... size_t addr = size_t(obj.a) << 17; printf("addr 0x%Ix\n", addr); //Output on 32-bit system: 0x80000000 //Output on 64-bit system: 0x80000000 |
The first example:
unsigned short a16, b16, c16; char *pointer; ... pointer += a16 * b16 * c16; |
This example works correctly with pointers if the value of "a16 * b16 * c16" expression does not exceed UINT_MAX (4Gb). Such code could always work correctly on the 32-bit platform for the program has never allocated arrays of large sizes. On the 64-bit architecture the size of the array exceeded UINT_MAX items. Suppose we would like to shift the pointer value on 6.000.000.000 bytes and that's why variables a16, b16 and c16 have values 3000, 2000 and 1000 correspondingly. While calculating "a16 * b16 * c16" expression all the variables according to C++ rules will be converted to int type and only then their multiplication will occur. During the process of multiplication an overflow will occur. The incorrect expression result will be extended to ptrdiff_t type and the calculation of the pointer will be incorrect.
One should take care to avoid possible overflows in pointer arithmetic. For this purpose it's better to use memsize types or explicit type conversion in expressions which carry pointers. We can rewrite the code in the following way using explicit type conversion:
short a16, b16, c16; char *pointer; ... pointer += static_cast |
If you think that only those inaccurate programs which work on larger data sizes face problems we have to disappoint you. Let's take a look look at an interesting code for working with an array containing only 5 items. The second example works in the 32-bit version and does not work in the 64-bit one.
int A = -2; unsigned B = 1; int array[5] = { 1, 2, 3, 4, 5 }; int *ptr = array + 3; ptr = ptr + (A + B); //Invalid pointer value on 64-bit platform printf("%i\n", *ptr); //Access violation on 64-bit platform |
Let's follow the calculation flow of the "ptr + (a + b)" expression:
Then calculation of "ptr + 0xFFFFFFFFu" takes place but the result of it depends on the pointer size on the particular architecture. If the addition will take place in a 32-bit program the given expression will be an equivalent of "ptr - 1" and we'll successfully print number 3.
In a 64-bit program 0xFFFFFFFFu value will be added fairly to the pointer and the result will be that the pointer will be outbound of the array. And we'll face problems while getting access to the item of this pointer.
To avoid the shown situation, as well as in the first case, we advise you to use only memsize types in pointer arithmetic. Here are two variants of the code correction:
ptr = ptr + (ptrdiff_t(A) + ptrdiff_t(B)); |
ptrdiff_t A = -2; size_t B = 1; ... ptr = ptr + (A + B); |
You may object and offer the following variant of the correction:
int A = -2; int B = 1; ... ptr = ptr + (A + B); |
Yes, this code will work but it is bad due to some reasons:
This kind of errors is separated from the others for better structuring of the account because indexing in arrays with the usage of square brackets is just a different record of address arithmetic observed before.
Programming in C and then C++ has formed a practice to use variables of int/unsigned types in the constructions of the following kind:
unsigned Index = 0; while (MyBigNumberField[Index] != id) Index++; |
But time passes and everything changes. And now it's a high time to say - do not do this anymore! Use memsize types for indexing (large) arrays.
The given code won't process an array containing more than UINT_MAX items in a 64-bit program. After the access to the item with UNIT_MAX index an overflow of the Index variable will occur and we'll get infinite loop.
To persuade you entirely in the necessity of using only memsize types for indexing and in the expressions of address arithmetic, I'll give the last example.
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]; } |
The given code is taken from a real program of mathematics simulation in which the size of RAM is an important resource, and the possibility to use more than 4 Gb of memory on the 64-bit architecture improves the calculation speed greatly. In the programs of this class one-dimensional arrays are often used to save memory while they participate as three-dimensional arrays. For this purpose there are functions like GetCell which provide access to the necessary items. But the given code will work correctly only with the arrays containing less than INT_MAX items. The reason for that is the use of 32-bit int types for calculation of the items index.
Programmers often make a mistake trying to correct the code in the following way:
float Region::GetCell(int x, int y, int z) const { return array[static_cast |
They know that according to C++ rules the expression for calculation of the index will have ptrdiff_t type and hope to avoid the overflow with its help. But the overflow may occur inside the sub-expression "y * Width" or "z * Width * Height" since the int type is still used to calculate them.
If you want to correct the code without changing types of the variables participating in the expression you may use explicit type conversion of every variable to memsize type:
float Region::GetCell(int x, int y, int z) const { return array[ptrdiff_t(x) + ptrdiff_t(y) * ptrdiff_t(Width) + ptrdiff_t(z) * ptrdiff_t(Width) * ptrdiff_t(Height)]; } |
Another solution is to replace types of variables with memsize type:
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]; } |
Mixed use of memsize and non-memsize types in expressions may cause incorrect results on 64-bit systems and can be related to the change of the input values rate. Let's study some examples.
size_t Count = BigValue; for (unsigned Index = 0; Index != Count; ++Index) { ... } |
This is an example of an eternal loop if Count > UINT_MAX. Suppose this code worked on 32-bit systems with the range less than UINT_MAX iterations. But a 64-bit variant of the program may process more data and it may need more iterations. As far as the values of the Index variable lie in the [0..UINT_MAX] range the "Index != Count" condition will never be executed and this will cause the infinite loop.
Another frequent error is recording expressions in the following form:
int x, y, z;
intptr_t SizeValue = x * y * z;
|
Similar examples were discussed earlier when during the calculation of values with the use of non-memsize types an arithmetic overflow occurred. And the last result was incorrect. Search and correction of the given code is made more difficult because compilers do not show any warning messages on it as a rule. This construction is absolytely correct for the C++ language. Several variables of int type are multiplied and after that the result is implicitly converted to intptr_t type and assignment occurs.
Let's provide an example of a small code fragment which shows the danger of inaccurate expressions with mixed types (the results are retrieved in Microsoft Visual C++ 2005, 64-bit compilation mode).
int x = 100000; int y = 100000; int z = 100000; intptr_t size = 1; // Result: intptr_t v1 = x * y * z; // -1530494976 intptr_t v2 = intptr_t(x) * y * z; // 1000000000000000 intptr_t v3 = x * y * intptr_t(z); // 141006540800000 intptr_t v4 = size * x * y * z; // 1000000000000000 intptr_t v5 = x * y * z * size; // -1530494976 intptr_t v6 = size * (x * y * z); // -1530494976 intptr_t v7 = size * (x * y) * z; // 141006540800000 intptr_t v8 = ((size * x) * y) * z; // 1000000000000000 intptr_t v9 = size * (x * (y * z)); // -1530494976 |
It is necessary that all the operands in such expressions have been converted to the type of larger capacity in time. Remember that the expression of the following kind:
intptr_t v2 = intptr_t(x) * y * z; |
does not promise the right result. It promises only that the "intptr_t(x) * y * z" expression will have intptr_t type. The right result shown by this expression in the example is good luck caused by a particular compiler version an0
