Our website uses cookies to enhance your browsing experience.
The purpose of this article is to answer some questions related to safe port of C/C++ code on 64-bit systems. The article is written as an answer to the topic often discussed on forums and related to the use of /Wp64 key and Viva64 tool.
Visual Studio 2005 and 2008 development environments are no longer supported. You can view the list of supported development environments in the documentation section "System requirements for PVS-Studio analyzer". Viva64 tool became a part of PVS-Studio product and is no longer distributed separately. All the abilities of searching for specific errors related to developing 64-bit applications, as well as porting code from 32-bit to 64-bit platform are now available within PVS-Studio analyzer.
I am a developer of a static code analyzer Viva64 [1], intended for diagnosing errors in 64-bit programs. The analyzer integrates into Visual Studio 2005/2008 environment and allows you to check if C/C++ code is correct according to the set of corresponding rules [2]. Potentially dangerous code sections detected by Viva64 tool may be analyzed and corrected in time and it reduces costs on testing and maintenance a lot [3].
While communicating with software developers on forums, via e-mail or at conferences I've noticed that there are some mistakes which lead to incorrect questions, remarks and comments. Within the limits of this article I want to try to clarify these points related to the use of 64-bit compilers, /Wp64 key and static analyzer Viva64. For that I will put several general questions and then answer them. I hope these answers will help you to better understand 64-bit technologies and find right solutions of different tasks.
Wp64 key tells the compiler to search possible errors which may occur during compilation of code for 64-bit systems. The check consists in that types marked in 32-bit code by __w64 keyword are interpreted as 64-bit types.
For example, we have the following code:
typedef int MyInt32;
#ifdef _WIN64
typedef __int64 MySSizet;
#else
typedef int MySSizet;
#endif
void foo() {
MyInt32 value32 = 10;
MySSizet size = 20;
value32 = size;
}Expression "value32 = size;" will cause contraction of value and consequently a potential error. We want to diagnose this case. But during compilation of a 32-bit application everything is correct and we won't get an warning message
To deal with 64-bit systems we should add /Wp64 key and insert __w64 keyword while defining MySSizet type in a 32-bit version. As a result the code will look like this:
typedef int MyInt32;
#ifdef _WIN64
typedef __int64 MySSizet;
#else
typedef int __w64 MySSizet; // Add __w64 keyword
#endif
void foo() {
MyInt32 value32 = 10;
MySSizet size = 20;
value32 = size; // C4244 64-bit int assigned to 32-bit int
}Now we'll get an warning message C4244 which will help us to prepare the port of the code on a 64-bit platform.
Pay attention that /Wp64 key doesn't matter for the 64-bit compilation mode as all the types already have the necessary size and the compiler will carry the necessary checks. It means that while compiling the 64-bit version even with /Wp64 key switched off we'll get C4244 message.
That's why, if you regularly compile you code in 64-bit mode you may refuse using /Wp64 in 32-bit code as in this mode the check is fuller. Besides, diagnosis systems with /Wp64 key is not perfect and often can cause false response or, just on the contrary, miss of messages. To learn more about this problem you may see the following links [4].
This question is one of the most frequent but it is actually incorrect. Let's at first refer to some analogy. Modern C/C++ compilers give a lot of messages warning about potential errors. But this doesn't decrease the urgency of such tools as lint, Gimpel PC-Lint, Parasoft C++test or Abraxas CodeCheck. And nobody asks what for we need these analyzers if Visual C++ compiler contains /Wp64 key or /Wall key?
The compiler's task is to detect syntax errors in programs and to give messages on the main potential type errors. The need of the diagnosis's details to be limited is related to the necessity of choosing a reasonable number of diagnoses that could be useful for all programmers. Another reason is the requirement that the compiler should be high-performance. Some checks take a lot of time but many programmers may not need it.
Universal static analyzers allow you to diagnose large classes of potential errors and bad coding style - that is, everything that is absent in the compiler. The static analyzer's settings are adjusted for concrete tasks and give detailed information about errors in which a developer is interested. Although static analyzers are launched regularly they are not launched during compilation of every file being developed. This allows you to carry rather deep analysis demanding more time. Static analysis is an excellent methodology among others which help to increase quality and safety of the code.
Similar to this is the situation with checking compatibility of the code with 64-bit systems. We have briefly discussed what we get with the help of /Wp64 key. This key is a great help for a programmer but it cannot be useful in every case. Unfortunately, there are much more cases of type errors related to the use of 64-bit systems. These type errors are described in detail in the article "20 issues of porting C++ code on the 64-bit platform" [5] which I strongly recommend you. It is the great difference in the number of checks provided by /Wp64 and the number of necessary checks why we need a specialized tool. Viva64 is such a tool.
There is one more related question: "Some analyzers such as Gimpel PC-Lint or Parasoft C++test support diagnosis of 64-bit errors. Why do we need Viva64 then?" It's true that these analyzers support diagnosis of 64-bit errors, but firstly it is not so thorough. For example, some errors related to the peculiarities of modern C++ language are not taken into consideration. And secondly, these analyzers work with Unix-systems data models and cannot analyze 64-bit programs developed in Visual Studio environment. To learn more about all this see "Forgotten problems of development of 64-bit programs" [6].
Summary: /Wp64 key and other static analyzers don't reduce the need of Viva64.
There is a wrong opinion that /Wp64 key is declared deprecated because diagnosis of 64-bit errors has become much better in Visual Studio 2008. But it is not so.
/Wp64 key is declared deprecated in Visual Studio 2008 only because it has become unnecessary. The time to "prepare for 64-bit code" has passed and now it's high time to create 64-bit programs. For that there is a 64-bit compiler in Visual Studio 2008 (as well as in Visual Studio 2005).
/Wp64 key is useful only in mode of compilation of 32-bit programs. It was created to detect some errors in time which the program will face in future after migration on 64-bit systems.
During compilation of a 64-bit program /Wp64 key is of no purpose. The compiler of 64-bit applications carries automatic checks similar to /Wp64 but more accurate. While compiling 32-bit programs /Wp64 mode glitched and it resulted in false error messages. It is not very pleasant and many developers complained of it and asked to upgrade this mode. Visual C++ developers have acted, in my opinion, very reasonably. Instead of wasting time on upgrading /Wp64 they declared it outdated. By this they:
Yes, it does as nothing has changed. The compiler hasn't changed much what creation of 64-bit programs is concerned. /Wp64 key in the 32-bit compiler was declared deprecated to stimulate switching to 64-bit systems but it doesn't concern Viva64. Viva64 analyzer detects much more potential "64-bit" errors than 64-bit compiler Visual C++ 2005/2008 and is used successfully by many developers.
I would like once more to devote some time to the fight with "evangelists" who propagate that the compiler can diagnose all the 64-bit errors and that refusing to use /Wp64 key just confirms it.
I ask you to reread the article "20 issues of porting C++ code on the 64-bit platform" [5]. Please, think about it!
The compiler cannot give messages on constructions of the following kind:
unsigned i;
size_t size;
for (i = 0; i != size; i++)
...Or, for example:
int x, y, z, w, h;
int position = x + y * w + z * w * h;
bigArray[position] = 0.0f;These are classical widely spread constructions. They are safe in most cases, and developers of compilers won't introduce warning messages on such constructions although they are potentially dangerous while porting on 64-bit systems! They should be analyzed at least once. Such errors are difficult to detect and they occur only in large data arrays or while processing a large number of items.
But all these problems can be easily solved if you look through the code with the help of Viva64. Please, don't deceive developers convincing them that everything is OK in their programs. You won't do them any good but may encourage them to switch to 64-bit systems carelessly and thus bring some rare errors which will occur only when a program will be launched..
0
0
0
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
0