I need to cast "HANDLE" to "long". I use the following code:
lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
But there is a warning in VC2005:
warning C4311: 'type cast' : pointer truncation from 'HANDLE' to 'long'
How can I solve this warning
Thanks!
You can do 2 things: use a pragma to eliminate the warning or change the declaration of lStdHandle from long to handle.
The problem here is that you assume that a pointer value will always fit in a long. It won't.
For 32 bit platforms this happens to work because they have the same size, but on a 64 bit platform, a long is still 32 bits and a handle 64 bits so yout code is 64 bit unclean.
EDIT: you can also lower your warning level, but I really wouldn't do that because then you hide potential problems.
I have the following for something similalr. There is likely a better way and I would pefer the better way but this is what I do now.
C4311 and C4312 are for portability issues. If you only intend to compile it for a 32 bit system then you can safely ignore this warning. Also turning the portability check off in the compiler options will stop the checks.
If you plan to compile it for x64 then you should take note of this warning. As was stated above, HANDLES are 64 bit on x64 machines, so putting them into a long is asking for trouble. As an addition to what Sdi said, what types you use are one of the _PTR types, INT_PTR, UINT_PTR etc. These are typedefed so their size changes with the platform and so you will not have these problems. As a side note/warning, if you compile a program using one of the above types with portability warnings on in a 32 bit program it will still give the warnings C4311/C4312, this is because of the way they are defined. If you plan to compile it for x64 it is actually a better idea to turn portability warnings off for the x86 compiler and then make sure you compile it with the x64 compiler too.
Sdi wrote:
To a first approximation, everything posted in response to the question is wrong (sorry guys). You don't squelch the warning with '#pragma warning', and you do care about it; this isn't VB, and type safety matters. You fix it by using the tools specifically provided by VS2005 for exactly this situation.
Thank you, but I disagree. It is wrong if it causes a problem, but my code is not a problem. What you could have said is that yes Sam, there is a better way. Instead you use the word "wrong" which should be reserved for extreme needs. In my reply, I said there is probably a better way. I think the world would be a better place if people made an effort to agree more than they do instead of allowing themselves to indulge in ridicule. If you think I should do that more, I agree.
I am not the person that asked the question, but I sure should have read the description of C4311 better, so I would have known that I could have turned off the option to check for compatibility with 64-bit. The article you referred to is very useful and I think the documentation of C4311 should refer to it, either directly or indirectly through the other article the documentation of C4311 does link to.
Maybe your code "is not a problem" for you, but it will be a problem for the future developer who has to clean it up for 64-bit and fix all the compile failures that "weren't a problem". Since we have 64-bit hardware and 64-bit OS's *now*, it is short-sighted to talk about "If you only intend to compile it for a 32 bit system", because that isn't our call; as developers, it is our job to produce the highest-quality code we can, and to not arbitrarily and unnecessarily limit our customer's options on using that code.
Yes, it's a bit of a pain to ensure that our code compiles cleanly at /W4 /WX with no warnings suppressed, but I've learned from years of doing it (and years of cleaning up code inherited from teams that *didn't* do it) that the long-term benefit far outweighs the short-term extra effort.
Is it really short sighted to say "If you only intend to compile it for a 32 bit system " There are pleanty of cases where this is possible, and these cases are where you can get sloppy with your code, BUT only these cases.
There have been pleanty of times when I have written a little application to automate a task that I only ever intended to use myself. These cases I do get lazy and I never produce code to the highest standard. But it is only here.
But I also think you missed the overall point of my post by quoting that. Yes I started off saying if you only intend, I never said that it was the right thing to do. In fact I went on to describe the best variables to use. Whats more, in the current environment, using the INT_PTR on a 32 bit machine will pull up a portability warning, so it is a better idea to just switch it off and then compile with the x64 compiler.
Maybe your code "is not a problem" for you, but it will be a problem for the future developer who has to clean it up for 64-bit and fix all the compile failures that "weren't a problem". Since we have 64-bit hardware and 64-bit OS's *now*, it is short-sighted to talk about "If you only intend to compile it for a 32 bit system", because that isn't our call; as developers, it is our job to produce the highest-quality code we can, and to not arbitrarily and unnecessarily limit our customer's options on using that code.
Yes, it's a bit of a pain to ensure that our code compiles cleanly at /W4 /WX with no warnings suppressed, but I've learned from years of doing it (and years of cleaning up code inherited from teams that *didn't* do it) that the long-term benefit far outweighs the short-term extra effort.
I used the word "wrong" only because you did. I was negative to you because you were negative. I hope you understand that there was totally no need to be negative in the manner you were. Since you strive to produce the highest quality code, why not strive to have the highest quality communication with others I am far from perfect, but I do try.
Is it really short sighted to say "If you only intend to compile it for a 32 bit system " There are pleanty of cases where this is possible, and these cases are where you can get sloppy with your code, BUT only these cases.
I think it is. Not necessarily because you will have to fix your code to be 64-bit clean, but because I've seen too many cases where someone else had to do so. If your code does anything non-trivial, there's a good chance that a year or two from now some other developer will find that it does almost exactly what s/he needs, and will grab it and use it. And find that it won't compile, because they're either specifically targeting 64-bit or at least have to be ready for 64-bit.
If it were really painful/expensive to write code that is 64-bit clean, the argument for quick-n-dirty 32-bit-only code might be stronger. But it just isn't that difficult to write 64-bit-ready code; it's mostly a matter of using the portable types and functions, and not doing things that are silly even though they work in 32-bit, like int/pointer type punning. I've been programming C and its follow-ons since 1979, and my experience is that 'sloppy' code doesn't really save anything; it just transfers the cost to someone downstream who has to fix the sloppy code.
Is it really short sighted to say "If you only intend to compile it for a 32 bit system " There are pleanty of cases where this is possible, and these cases are where you can get sloppy with your code, BUT only these cases. I think it is.
Note that the warning goes away when the option is chosen to not warn of portability issues.