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 ...
I often hear in various interpretations the phrase: "The given examples show not the code incorrect from the viewpoint of porting to x64 systems, but the code incorrect in itself". I would like to discuss and theorize a bit on this point in the blog. Please, take this note with a bit of humor.
In forums, people often say that 64-bit versions of programs consume a larger amount of memory and stack. Saying so, they usually argue that the sizes of data have become twice larger. But this statement is unfounded since the size of most types (char, short, int, float) in the C/C++ language remains the same on 64-bit systems. Of course, for ...