SetWindowLongPtr() problem with /Wp64 switch

When writing code that will used for both 32-bit and 64-bit Windows, there are functions that you should use so that you will not have to change any code during the switch. These functions work in both modes. One of them is the SetWindowLongPtr Function.

As described in Rules for Using Pointers, the way you should update your code is like the following:

Code:

---

For example, the following code does not compile:

SetWindowLong(hWnd, GWL_WNDPROC, (LONG)MyWndProc);

It should be changed as follows:

SetWindowLongPtr(hWnd, GWLP_WNDPROC, (LONG_PTR)MyWndProc);

---

On my system, MSVC++ .NET 2003 (version 7.1) compiling for 32-bit mode with the /Wp64 (Detect 64-Bit Portability Issues) switch on, the new code does not compile smoothly. I get the following warning:

Code:

---

warning C4244: 'argument' : conversion from 'LONG_PTR' to 'LONG', possible loss of data

---

The code compiles fine when I turn the /Wp64 switch off.

Bug confirmed by the following website:
http://msdn.microsoft.com/msdnmag/is.../08/bugslayer/

Quoted from 'Other Interesting New Compiler Things' section:
"I've found /Wp64 to be quite helpful, except that the SetWindowLongPtr/GetWindowLongPtr macros, which are supposed to aid 32- and 64-bit access, are defined wrong when doing 32-bit compiles. So with /Wp64, you will have extra warnings around them unless you turn them off with the #pragma warning directives."

Unfortunately, the flag /Wp64 often leads incorrect and insufficient diagnostics. I recommend to switch off this flag and to use for check special lint-like static analyzers of a code. For example - Viva64.
http://www.viva64.com

Quote:

---

Originally Posted by Karpov2007

Unfortunately, the flag /Wp64 often leads incorrect and insufficient diagnostics. I recommend to switch off this flag and to use for check special lint-like static analyzers of a code. For example - Viva64.
http://www.viva64.com

---

I completely disagree. If the definitions for SetWindowLongPtr() were proper, there would not be an issue. I have not had any other issues with /Wp64. All it has done for me, other than this current issue, is shown me incorrect code (code that will fail during a switch to 64-bit) numerous times... exactly what it was meant to do. Therefore, I highly recommend using it.

Of course, this says nothing about the utility of the product you mention... but, no matter its utility, it does not warrant the disabling of the /Wp64 switch.

In the beginning I wish to apologize, that has made the answer to for a long time asked question. Simply I am interested in subjects of migration programs on 64-bit systems and I look through various messages on the given theme. And answering, I have not paid attention to date. :)

I do not call to off /Wp64. It really very useful key. But I wished to inform, that there is utility Viva64. Which makes the alternative analysis of a code on compatibility with the 64-bit environment. Also has suggested to use it.
And in occasion of disable /Wp64 I have got excited.

And still I have decided to give an example, when Viva64 can render the additional help. An example of an infinite cycle, if n> UINT_MAX:

size_t n;
unsigned i;
for (i = 0; i != n; ++i) { ... }
( Look http://www.viva64.com/help/V104.html )

It by the way rather real example more in detail. The size of a processable data on a 64-bit platform became more than 4 Gb and then n> UINT_MAX. But I think, that you will not like the compiler which will give out warning on each second cycle. So should act /Wp64 if carried out given diagnostics. And wrong there can be only one cycle. Static the analyzer just will show on all suspicious places of the warnins. That the analyzer will allow to see all potentially dangerous places connected with porting of the application on other platform and to correct a code.