Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you haven't received our response, please do the following:
check your Spam/Junk folder and click the
"Not Spam" button for our message.
This way, you won't miss messages from our team in the future.
64-bit errors are a thing of the bygone days. Very few developers are porting code from a 32-bit to a 64-bit system these days. Those who needed it have already ported their programs. Those who don't need it, they likely won't have to. But sometimes such errors make us recall them.
The short article "Adventures in application compatibility: The case of the display control panel crash on exit" brought the 64-bit errors issue to my mind. Perhaps our readers do not know or forgot that the PVS-Studio static analyzer was initially developed as a tool to detect 64-bit errors. At that time, the tool used to be called Viva64. So, the 64-bit errors issue is very close to us and makes us feel nostalgic :).
By 64-bit errors, we mean such code defects that may occur when porting an app from the 32-bit system to the 64-bit one. However, the code is incorrect on both systems. But it's just fortune that the code is running on the 32-bit system. Let's look at the following synthetic code fragment:
void *ptr = foo();
unsigned num = (unsigned)(ptr);
ptr = (void *)(num);Someone decided to store the pointer value to the variable of the unsigned type. The code is incorrect. However, the sizes of the pointer and the variable of the unsigned type are the same on the 32-bit system, so everything works well. The problem occurs in the 64-bit system, where the unsigned type has most likely a 32-bit size and pointers become 64-bit. It will cause the loss of high bits in the pointer, when running the code. To prevent this, replace unsigned with uintptr_t.
This is exactly the case described in the mentioned article. The old Windows driver contains the code where the value is casting to LONG instead of LONGP_PTR:
SetWindowLong(GetDlgItem(m_dlg, IDC_SOME_BUTTON),
GWL_WNDPROC, (LONG)g_originalWndProc);Windows x64 has adopted the LLP64 data model in which variables of the long type (and LONG) are still 32-bit, as is the int type. It results in the loss of the high 32 bits, when casting to the LONG type. Here is the correct example:
SetWindowLong(GetDlgItem(m_dlg, IDC_SOME_BUTTON),
GWL_WNDPROC, (LONG_PTR)g_originalWndProc);In the article, such an old bug in the old driver requires editing directly in the executable binary code. "The later you find the problem, the harder and more expensive it is to fix it" principle is in action.
If you face the problem of porting code to the 64-bit system one day or are searching for errors in the already ported code, you are welcome to visit our website. There you will find the following:
0
0
0
0