warning C4312: /Wp64 switch of any use?
Author
After reading up on this for some time, and getting many threads like this one:
http://www.gamedev.net/community/forums/topic.asp?topic_id=355259
It seems like the "detect portability issues" switch in VS2005/VS2003 is a ridiculous joke.
Even if you make your code "portable", by changing your typecasts:
eg:
long to LONG_PTR
int to INT_PTR
...the warnings persist, when compiling for WIN32. It's silly that even something like this gets a warning:
long id = 0;
SetWindowLongPtr(hwndparent, GWLP_ID, (std::size_t)(id));
...when in practice, it would compile fine under WIN64.
Thoughts? Is there a way to create code that is both portable between 32/64 AND can satisfy the compiler with the switch enabled? Or am I just wrong about the whole thing?
[Edited by - Verg on May 6, 2007 1:43:22 PM]
Platform specific API might not be portable.
This may seem strange, but HWND in your case doesn't need to be. Platform API is provided for each platform independantly, and only needs to be "portable" for its own purposes.
What works in practice doesn't imply what is correct at language level. In practice, code that was only written for 32-bits may work flawlesly in 64-bit environment.
Also: HWND is either a pointer to struct or void*, and size_t is unsigned int.
There's no chance this would pass any test whatsoever. As a matter of fact, any assignment of a pointer to number is frowned upon.
Edit: Since you edited your original example: long and unsigned int (or size_t) are not mutually assignable. At very least, there's the sign issue.
Bottom line is: Windows API wasn't designed for portability, so it's not only full of hacks, but much of its design is flawed from that perspective.
This may seem strange, but HWND in your case doesn't need to be. Platform API is provided for each platform independantly, and only needs to be "portable" for its own purposes.
What works in practice doesn't imply what is correct at language level. In practice, code that was only written for 32-bits may work flawlesly in 64-bit environment.
Also: HWND is either a pointer to struct or void*, and size_t is unsigned int.
There's no chance this would pass any test whatsoever. As a matter of fact, any assignment of a pointer to number is frowned upon.
Edit: Since you edited your original example: long and unsigned int (or size_t) are not mutually assignable. At very least, there's the sign issue.
Bottom line is: Windows API wasn't designed for portability, so it's not only full of hacks, but much of its design is flawed from that perspective.
Author
Yeah, I changed the "hwnd" example for exactly the reason you pointed out. I was trying to come up with a trivial example off the top of my head...
As far as "long" to "size_t", it's really a trivial example. I could have used "unsigned long". VS2005 still spits out a C4312 on anything resembling the SetWindowLongPtr that I've described.
Casting to (LONG_PTR) (which is signed) has the same effect.
My question was really is the /Wp64 switch really necessary, when the 64-bit compiler is available itself? Why not just run the code through it, when wanting to create 64-bit code?
I guess the difficulty is in wanting to use 32-bit executables on 64-bit versions of Windows--but from what I'm led to believe, those run fine under WOW.
As far as "long" to "size_t", it's really a trivial example. I could have used "unsigned long". VS2005 still spits out a C4312 on anything resembling the SetWindowLongPtr that I've described.
Casting to (LONG_PTR) (which is signed) has the same effect.
My question was really is the /Wp64 switch really necessary, when the 64-bit compiler is available itself? Why not just run the code through it, when wanting to create 64-bit code?
I guess the difficulty is in wanting to use 32-bit executables on 64-bit versions of Windows--but from what I'm led to believe, those run fine under WOW.
I tried various static code checkers.
They trigger such warnings not only on one call, but you're likely to have your code littered with them.
I'm unable to currently point out a good example, but there's really lots of tricky details to watch when dealing with various types - overflow being the simplest of them.
Once you get down to pointers and pointer arithmetic, things get even worse.
These problems are incredibly unlikely to show up in practice, but that doesn't mean they should be ignored.
BTW: googling for your problem shows up it's an API foobar that causes that warning, where it shouldn't be.
http://pluralsight.com/blogs/keith/archive/2005/01/13/4940.aspx
So, yes and no. It is a portability issue, and no, it's not your fault, but the compiler is pointing out a problem in API. This is unfortunately likely to happen.
They trigger such warnings not only on one call, but you're likely to have your code littered with them.
I'm unable to currently point out a good example, but there's really lots of tricky details to watch when dealing with various types - overflow being the simplest of them.
Once you get down to pointers and pointer arithmetic, things get even worse.
These problems are incredibly unlikely to show up in practice, but that doesn't mean they should be ignored.
BTW: googling for your problem shows up it's an API foobar that causes that warning, where it shouldn't be.
http://pluralsight.com/blogs/keith/archive/2005/01/13/4940.aspx
So, yes and no. It is a portability issue, and no, it's not your fault, but the compiler is pointing out a problem in API. This is unfortunately likely to happen.
Author
Thanks for the link. I didn't think to look for specifically SetWindowLongPtr, since (as you said) the code had quite a few more of these warnings.
Casting to LONG_PTR didn't work in any of those cases either. /Wp64 switch is disabled now. When I run the code thru the 64-bit compiler, I'll turn it on.
Thanks again.
Casting to LONG_PTR didn't work in any of those cases either. /Wp64 switch is disabled now. When I run the code thru the 64-bit compiler, I'll turn it on.
Thanks again.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
