On forums I'm constantly asked questions concerning search of incorrect explicit type conversion when porting code on a 64-bit platform. I decided to write this small note so that I could refer people to it and avoid writing the answer every time.The description of the problem looks approximately as shown below:
"Debugging bad pointer casts in 64bits" I am currently converting a program to Windows 64bits. Some bad code casts pointers into long and vice-versa. Code example: MyObj* pObj = ... ::SendMessage(hwnd, msg, (WORD)x, (DWORD)pObj);
The problem is that it is impossible to detect such errors with the help of the compiler as explicit type conversion is used which suppresses diagnostic messages. The static code analyzer Viva64 is used for diagnosing these and many other errors. (http://www.viva64.com/viva64-tool/).
Viva64 is a specialized commercial tool for searching errors in C/C++ programs when porting them on 64-bit systems or developing new 64-bit programs. Besides, the tool allows you to better optimize 64-bit code. The tool is rather expensive but our users can get support in setting and improving the tool according to the peculiarities of their projects what makes the tool very effective.
This tool serves for detecting explicit type conversions which are dangerous from the viewpoint of a 64-bit data model.
For example, on the code given above the analyzer will show warning V202:
V202. Explicit type conversion. Type casting from memsize to 32-bit. http://www.viva64.com/content/PVS-Studio-help-en/V202.html
And on the following code where incorrect explicit type conversion from a 32-bit to a 64-bit type is used:
unsigned width, height, depth; DWORD_PTR arraySize = DWORD_PTR (width * height * depth);
you'll get warning V201:
V201. Explicit type conversion. Type casting to memsize.
Conclusion: if you have a large code it is more reasonable not to perform eternal testing catching new overflows/cut of values at the next set of input data but to buy Viva64 and catch these errors at the very early stages.
The analyzer considers the last fragment of the code suspicious, as it is very similar to a typical error. The fact is, that if width, height and depth meanings are quite large, during multiplication, 32-bit type unsigned overflow can occur. And this incorrect result will be expanded to 64-bit DWORD_PTR type and placed in arraySize variable. There is high probability that the code should be rewritten in the following way:
unsigned width, height, depth; DWORD_PTR arraySize = DWORD_PTR (width) * DWORD_PTR (height) * DWORD_PTR (depth);
In this case, 64-bit types will be multiplied, and the overflow will disappear. Such situations are described in detail in the article "20 Issues of Porting C++ Code on the 64-bit Platform" (http://www.viva64.com/art-1-2-599168895.html).
We have already written in our articles about one of the problems of code migration to 64-bit systems relating to incorrect overload of virtual functions. For example, our article "20 issues of porting C++ code on the 64-bit platform" was published in March, 2007 (although is still relevant). It described the issue of virtual functions. The point of the problem ...
In C language, you may use functions without defining them. Pay attention that I speak about C language, not C++. Of course, this ability is very dangerous. Let us have a look at an interesting example of a 64-bit error related to it. Below is the correct code that allocates and uses three arrays, 1 GB each: