Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

As mentioned on the blog post's comments, it's often caused either by storing a pointer in a DWORD variable (very common on 32-bit Windows), or by storing a pointer in a "long" variable (on most common 32-bit and 64-bit platforms, a "long" is at least as wide as a pointer; the main exception is 64-bit Windows).

The correct variable type to store a pointer would be intptr_t/uintptr_t for portable software (and DWORD_PTR for Windows-only software), but the "intptr" types didn't exist until the 1999 C standard (and, as far as I could find, the default Windows compiler didn't add the corresponding header file until around 2010). Software older than that would often assume that a "long" (or a DWORD, which IIRC was just another name for "long") was big enough to store a pointer, or perhaps tried to use the C99 types and used "long" if the header wasn't found.



> storing a pointer in a DWORD variable (very common on 32-bit Windows)

Is it? I mean, if you're lucky it won't cause a compiler warning on x86, but the sane thing to do is to use the types which the API docs specify. Which would usually be things like LPVOID or HANDLE.

That's basically how I managed to port a service and several drivers to 64-bit Windows many years ago with almost no changes.


At the time the code was written the warnings you get now didn't exist. Then the 32-bit code worked, so nobody needed to change the it. Now with windows 8 they see it for the first time that it doesn't work.

I know as I also worked on the huge codebase where the oldest pieces of the code were written around 1995.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: