![]() PVS-Studio Static Code Analyzer for 64-bit and parallel C/C++ code
|
|||||
![]() ![]() ![]() ![]() ![]()
02.03.2010
Parallel notes N3 - base OpenMP constructs Now we would like to start introducing you into OpenMP technology and show you the ways of using it.»
28.02.2010
In what way can C++0x standard help you eliminate 64-bit errors Programmers see in C++0x standard an opportunity to use lambda-functions and other entities I do not quite understand :).»
26.02.2010
CruiseControl.NET - build automation platform Continuous integration While developing software products with a complicated structure, you come at some moment to the necessity of automating the processes of building and integrating the projects and distribution kits being developed.» ![]()
10.12.2009
PVS-Studio FAQ This paper contains some questions and answers about PVS-Studio code analyzer by OOO "Program Verification Systems".»
09.12.2009
VivaCore FAQ This paper contains some questions and answers about VivaCore C/C++ code analysis library by OOO "Program Verification Systems"»
23.11.2009
PVS-Studio: using the function "Mark as False Alarm"
The article describes and demonstrates by an example the use of PVS-Studio 3.40 new function "Mark as False Alarm". » ![]() |
64-bit Development![]() 64 bits, Wp64, Visual Studio 2008, Viva64 and all the rest...
Andrey Karpov
| ||||
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, 5].
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" [6] 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" [7].
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" [6]. 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..