Search for explicit cast to 32-bit type

The Visual Studio C ++ compiler has warning C4311 ('variable': pointer truncation from 'type' to 'type') designed to detect errors when casting a pointer to 32-bit data types. In Intel C ++, warning # 810 corresponds to this warning. Example of a detected defect:

void * ptr = x;
int y = (int) ptr;

In Win64, the size of the pointer became 64-bit, and the size of the int remained as before 32 bits. Explicit type conversion will truncate the value of the pointer, which will lead to an error if the pointer refers to an object located outside the lower 4 GB of memory (0x00000000FFFFFFFF).

Such errors are insidious in that they can occur irregularly. However, they can be easily detected by looking at all compiler warnings with the number C4311. But using this check itself there is some unpleasant nuance.


If you simply create a 64-bit project in Visual Studio 2008/2010 and write the code above, you will not receive warning C4311. We will understand the reasons for this unexpected situation.

Visual Studio 2003/2005 has the / Wp64 switchdesigned to identify some problems that a programmer will encounter when building his code in a 64-bit version. This warning group also includes warning C4311. If you create a project in Visual Studio 2005, then even in the 32-bit configuration for the line “int y = (int) ptr;” a warning will be generated:

warning C4311: 'type cast': 
pointer truncation from 'void *' to 'int'.

The / Wp64 switch was intended to somehow prepare applications for a 64-bit platform without the need for a 64-bit configuration. However, the time to “prepare” has passed. Starting with Visual Studio 2005, there is a 64-bit compiler. If you want to support the Win32 and Win64 platform, then you need to have two project configurations. In the x64 configuration, using the / Wp64 switch is pointless, which is why it is deprecated in Visual Studio 2008/2010.

Everything would be fine, but it seems to me that Visual Studio developers made a logical mistake. If you create a new project in Visual Studio 2008/2010 or convert the old project to a new one, the / Wp64 switch will not be installed. It is right. Even if you specify / Wp64 specially in the “Additional Options” of the project, a message will be displayed:

Command line warning D9035: 
option 'Wp64' has been deprecated and will be removed in a future release.

The humor of the situation is that warnings such as C4311 , C4312 , C4313 are for some reason still associated with the / Wp64 switch. And if it is not, then there are no these warnings, although their level of danger is Level 1 .

These warnings will return if you enable / Wp64 and receive D9035 warnings about an obsolete option. Another option is to enable / Wall. Messages will be issued, but this is the way, as you know, only for the brave. Apparently the most sensible option is to use #pragma warning in stdafx.h.

Now let's move on to Intel C ++. Starting to study the question, I expected that in its behavior with respect to / Wp64 it is equivalent to Visual C ++. It turned out that he had everything in his own way. He also found the error of the type “int y = (int) ptr;” without the / Wp64 switch, giving warning # 810. But warning # 967 (equivalent to C4312) already requires / Wp64. It turns out that the Intel C ++ compiler also has a warning set associated with / Wp64, but this set itself is different. Since it has historically been that the documentation on the exotic features of Intel C ++ is tight, I have not found what exactly includes / Wp64.

After all this stream of thoughts, the reader may ask:

But what's the catch then? I ask you briefly again. Answer. If you have a project for Visual Studio 2008/2010 and create a 64-bit configuration, then you will not see a warning for such commonplace errors as: void * ptr = x; int y = (int) ptr; // C4311 int i = x; return (void *) i; // C4312 int * pI = 0; printf ("% d", pI); // C4313 And apparently some others. Assembling the same project using Intel C ++, you will not see another set of errors. To receive all these beneficial warnings, you must explicitly enable them yourself! This is not difficult to do, provided that you know about it. I haven’t known for a long time, although I am interested in the topic of developing 64-bit applications.

I emphasize that defeating these warnings does not mean the correctness of a 64-bit program. It only means that the most obvious defects have been fixed. So to say, "who did not hide, I am not to blame." But for the detection of “those who hid” in a large project, it makes sense to use specialized tools ( Viva64 ).

Of course, I was not the first to notice this imperfection regarding 64-bit warnings. More recently , a comment on this topic has been left here . Please note that the criticism is completely fresh.

From all this, I can conclude that people are just starting to be interested in creating Win64 applications. I wrote this phrase a year ago, and now I repeated it again. It is very strange. I do not believe that you can develop normal programs without even being interested in where the pointer is pushed into int. The lack of mass discussions on the Internet of such issues is extremely embarrassing to me. I don’t understand how the world works.