📜 ⬆️ ⬇️

Search for an explicit pointer to a 32-bit type

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

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

In Win64, the pointer size was 64-bit, and the int size was still 32 bits. Explicit type casting cuts the pointer value, which will lead to an error if the pointer refers to an object outside the lower 4 GB of memory (0x00000000FFFFFFFF).

Such errors are insidious because they can manifest irregularly. However, they can be easily detected by reviewing all the 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 warnings C4311. We will understand the reasons for this unexpected situation.

In Visual Studio 2003/2005, there is a / Wp64 switch designed to identify some problems the programmer will encounter when building his code in the 64-bit version. The warning group C4311 also belongs to the group of warnings. If you create a project in Visual Studio 2005, then even in the 32-bit configuration for the string “int y = (int) ptr;” a warning will be generated:

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

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

Everything would be fine, but I think the developers of Visual Studio made a logical error. If you create a new project in Visual Studio 2008/2010 or convert an old project to a new one, then the / Wp64 switch will not be installed. It is right. Even if you specifically register / Wp64 in the Additional Options of the project, you will get the message:

  Command line warning D9035: 
 option 'Wp64' has been removed. 

The humor of the situation is that such warnings as C4311 , C4312 , C4313 for some reason are still associated with the / Wp64 key. 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 understand, only for the brave. Apparently the most reasonable option is to use #pragma warning in stdafx.h.

We now turn to Intel C ++. Starting the study of the question, I expected that in my behavior relative to / Wp64 it is equivalent to Visual C ++. It turned out that he had everything in his own way. An error of casting the form “int y = (int) ptr;” he found without the / Wp64 key, issuing warning # 810. But warning # 967 (equivalent to C4312) already requires / Wp64. It turns out that the Intel C ++ compiler also has a set of warnings associated with / Wp64, but this set itself is different. Since it has historically developed that the documentation on the exotic features of Intel C ++ is tight, I did not find out what exactly / Wp64 includes.

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

And in what all the same zakovyrka that? Please briefly again.

Answer. If you have a project for Visual Studio 2008/2010 and create a 64-bit configuration, then you will not see warnings for such trivial errors as:

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

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

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

And apparently some others. By compiling the same project using Intel C ++, you will not see another set of errors.

To get all these salutary warnings you must explicitly enable them yourself! It 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 subject of developing 64-bit applications.

I emphasize that a victory over these warnings does not at all mean the correctness of a 64-bit program. This only means that the most obvious defects have been corrected. So to say "who did not hide, I am not guilty." But to detect “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 flaw regarding 64-bit warnings. Most recently , a comment was posted here on this topic. Please note that the criticism is quite fresh.

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

Source: https://habr.com/ru/post/106411/

All Articles