C / C++ / MFC

Karpov2007 wrote:

The computer industry is changing, and 64-bit technology is the next, inevitable step.

WalderMort wrote:

There is nothing "changing" at all, 64-bit systems have been around for a long time. What you think 64-bit XP was the first...

WalderMort wrote:

If you have a decent compiler, it will notify you about the 64-bit compatibility issues like in your example. Unless of course you don't like the warnings and turned the feature OFF!

int  *ptr = array + 3;    // ptr = 0x000000000012feb4
ptr = ptr + (a + b);      // ptr = 0x000000040012feb0 
                                            ^

As posted by OP
0000000000401078  mov         eax,dword ptr [b] 
000000000040107C  mov         ecx,dword ptr [a] 
0000000000401080  add         ecx,eax 
0000000000401082  mov         eax,ecx 
0000000000401084  mov         eax,eax  <--- looks like an effective no-op to me (rax == eax)
0000000000401086  mov         rcx,qword ptr [ptr] 
000000000040108B  lea         rax,[rcx+rax*4]  <--- bad math, rax wrong
000000000040108F  mov         qword ptr [ptr],rax 
 
Change 'unsigned b = 1;' to 'int b = 1;'
0000000000401078  mov         eax,dword ptr [b] 
000000000040107C  mov         ecx,dword ptr [a] 
0000000000401080  add         ecx,eax 
0000000000401082  mov         eax,ecx 
0000000000401084  cdqe        <--- convert DWORD to QWORD  (rax = sign extend of eax)
0000000000401086  mov         rcx,qword ptr [ptr] 
000000000040108B  lea         rax,[rcx+rax*4]  <--- good math, rax correct
000000000040108F  mov         qword ptr [ptr],rax

int _tmain(int argc, _TCHAR* argv[])
{
	int       a = -2;
	unsigned  b =  1;
	int       array[5] = { 1, 2, 3, 4, 5 };
	int      *ptr = array + 3;

	ptr = ptr + (a + b);   // Invalid pointer value on 64-bit platform
	printf("%i\n", *ptr);  // Access violation on 64-bit platform

	return 0;
}

class CWinApp {<br />
  ...<br />
  virtual void WinHelp(DWORD_PTR dwData, UINT nCmd);<br />
  ...<br />
};<br />
<br />
class CSampleApp : public CWinApp {<br />
  ...<br />
  virtual void WinHelp(DWORD dwData, UINT nCmd);<br />
  ...<br />
};

cmk wrote:

The problem is with the unsigned b, change it to int b and everything is fine again.

cmk wrote:

To me this _should_ be a compiler bug.
The OP seems to imply it is correct (though possibly unexpected) behaviour for x64 compilers.

1. Working
long   a[] = {1, 2, 3};  // &a[0] == 00000000-0012feb8
long   b   = -1;
long  *p   =  a + 2;
 
p = p + b;
 
movsxd      rax,dword ptr [b] ; rax = ffffffff-ffffffff
mov         rcx,qword ptr [p] ; rcx = 00000000-0012fec0
lea         rax,[rcx+rax*4]   ; rax = 00000000-0012febc
            ; rax*4 overflows gives ffffffff-fffffffc
            ; rcx + (rax*4) overflows, net effect is to sub 4 from rcx
            ; net effect is that we get the right value                 
mov         qword ptr [p],rax ; p   = 00000000-0012febc

2. Working, compiles using entirely different strategy
 long   a[] = {1, 2, 3};  // &a[0] == 00000000-0012feb8
ulong   b   =  1;         // change to unsigned
 long  *p   =  a + 2;
 
p = p - b;
 
mov         eax,dword ptr [b] ; eax  = 1, rax = 00000000-00000001
shl         rax,2             ; rax *= 4, rax = 00000000-00000004
mov         rcx,qword ptr [p] ; rcx  = 00000000-0012fec0
sub         rcx,rax           ; rcx  = 00000000-0012febc
mov         rax,rcx           ; rax  = 00000000-0012febc
mov         qword ptr [p],rax ; p    = 00000000-0012febc

3. Fails, back to OP problem
 long   a[] = {1, 2, 3};  // &a[0] == 00000000-0012feb8
ulong   b   =  1;
 long  *p   =  a + 2;
 
p = p + (-b);  // the only change
 
mov         eax,dword ptr [b] ; eax =        1, rax = 00000000-00000001
neg         eax               ; eax = ffffffff, rax = 00000000-ffffffff
mov         eax,eax           ; noop, rax goes forth un sign extended
mov         rcx,qword ptr [p] ; rcx = 00000000-0012fec0
lea         rax,[rcx+rax*4]   ; rax = 00000040-0012febc
            ; rax = 00000000-0012fec0 + (00000000-ffffffff * 4)
            ; rax = 00000000-0012fec0 +  00000003-fffffffc  <- damn
mov         qword ptr [p],rax ; p   = 00000040-0012febc

cmk wrote:

To me this _should_ be a compiler bug.

cmk wrote:

I know _someone_ will say that even wrong code can produce right results now and then, to which i say

WalderMort wrote:

...then open the file with CreateFile() or fopen(), read each line and do a string comparison for your string with strstr().