To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Searching for explicit conversion of a …

Searching for explicit conversion of a pointer to a 32-bit type

Oct 19 2010

In Visual Studio C++ compiler, there is the warning C4311 ('variable' : pointer truncation from 'type' to 'type') intended to detect errors of casting a pointer to 32-bit data types. This warning corresponds to warning #810 in Intel C++.

This is an example of the defect they diagnose:

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

In Win64, the pointer's size is 64-bit while the int type's size is still 32 bits. Explicit type conversion truncates the pointer's value, which will cause an error in case the pointer refers to an object situated outside the first 4 low-order Gbytes (0x00000000FFFFFFFF).

What is bad about such errors is that they occur irregularly. But you can easily find them reviewing all the compiler's warnings with number C4311. However, there is a subtle unpleasant trouble about using this very diagnosis.

If you simply create a 64-bit project in Visual Studio 2008/2010 and write the above mentioned code, you will not get the C4311 warning. Let's find out why.

In Visual Studio 2003/2005, there is the /Wp64 switch intended for detecting some problems the programmer will encounter when building his code in the 64-bit version. Warning C4311 is among these warnings. If you create a project in Visual Studio 2005, the warning will be generated even in the 32-bit configuration for the line "int y = (int)ptr;":

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

The /Wp64 switch was meant to at least somehow prepare applications for the 64-bit platform without creating the 64-bit configuration. However, the time of "getting ready" has passed. Starting with Visual Studio 2005, the environment provides a 64-bit compiler. If you want to support both Win32 and Win64 platforms, you must have two configurations of your project. It is unreasonable to use the /Wp64 switch in x64 configuration, so it was declared deprecated in Visual Studio 2008/2010.

Everything would be all right, 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 an old project into a new one, the /Wp64 switch will be disabled. It is ok. Even if you define /Wp64 deliberately in the project's "Additional Options", you will get this message:

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

What is humorous about this situation is that warnings C4311, C4312 and C4313 are still related to the /Wp64 switch for some reason. If the switch is absent, these warnings are absent as well, although they have Danger Level 1.

These warnings will come back if you enable /Wp64 and get warnings D9035 about an obsolete option. Another way is to enable /Wall. The messages you need will be generated, but this way, as you may see, is only for the brave ones. Using #pragma warning in stdafx.h seems to be the most reasonable way.

Now let's speak about Intel C++. When I started studying this issue, I was expecting that its behavior concerning /Wp64 was similar to that of Visual C++. But I found out that it went its own way. It detected the conversion error of the "int y = (int)ptr;" kind even without the /Wp64 switch by generating warning #810. But warning #967 (equivalent to C4312) demanded /Wp64. It turns out that the Intel C++ compiler also has a set of warnings related to /Wp64 but the set itself is different. Since it is a historically established situation that there is no documentation on exotic specifics of Intel C++, I failed to find out what particular thing enables /Wp64.

After this flow of thoughts and words, the readers may ask:

What is the problem after all? Tell me again in short, please.

Here is the answer. If you have a project for Visual Studio 2008/2010 and create the 64-bit configuration, you will fail to see warnings for trivial errors like these:

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

int i = x;
return (void*)i; // C4312

int * pI = 0;
printf("%d", pI); // C4313

and perhaps for some others too. If you build the same project with Intel C++, you will fail to get another set of errors.

To get all those good warnings, you must enable them yourself! It is not hard to do if you know about it. As for me, I have not known about it, although I am involved in the sphere of 64-bit software development.

I want to point it out that conquering these warnings does not necessarily mean making a 64-bit program correct. It only means that you have fixed the most obvious defects - so to say, "who doesn't hide, I will find". But to find "those who hide" in large projects, you should use specialized tools (Viva64).

Of course, I was not the first who noticed this defect concerning 64-bit warnings. A comment on this topic was posted right recently here. Note that the criticism is very fresh.

Summing it all, I may say that people are only beginning to get interested in creating Win64 applications. I wrote this phrase a year ago and now repeat it again. It is very strange. I do not believe that one can develop good applications without studying places where a pointer is crammed into the int type. Absence of mass discussions of such issues on the Internet embarrasses me very much. I do not understand how the world is arranged.

Popular related articles
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →