为什么这个添加的byte *和uint无法进入更高的dword？

Question

Now filed on Microsoft Connect ; please upvote if you feel it needs fixing. I've also simplified the test case a lot:

byte* data = (byte*) 0x76543210;
uint offset = 0x80000000;
byte* wrong = data + offset;
byte* correct = data + (uint) 0x80000000;

// "wrong" is now 0xFFFFFFFFF6543210 (!)
// "correct" is 0xF6543210

Looking at the IL, as far as I can tell, the C# compiler did everything right, and the bug lies in the JITter.

---

Original question : What is going on here?

byte* data = (byte*)Marshal.AllocHGlobal(0x100);

uint uioffset = 0xFFFF0000;
byte* uiptr1 = data + uioffset;
byte* uiptr2 = data + (uint)0xFFFF0000;

ulong uloffset = 0xFFFF0000;
byte* ulptr1 = data + uloffset;
byte* ulptr2 = data + (ulong)0xFFFF0000;

Action<string, ulong> dumpValue =
    (name, value) => Console.WriteLine("{0,8}: {1:x16}", name, value);

dumpValue("data",     (ulong)data);
dumpValue("uiptr1",   (ulong)uiptr1);
dumpValue("uiptr2",   (ulong)uiptr2);
dumpValue("ulptr1",   (ulong)ulptr1);
dumpValue("ulptr2",   (ulong)ulptr2);

This test requires a 64-bit OS targeting the x64 platform.

Output:

data: 000000001c00a720    (original pointer)
uiptr1: 000000001bffa720    (pointer with a failed carry into the higher dword)
uiptr2: 000000011bffa720    (pointer with a correct carry into the higher dword)
ulptr1: 000000011bffa720    (pointer with a correct carry into the higher dword)
ulptr2: 000000011bffa720    (pointer with a correct carry into the higher dword)
               ^
               look here

So is this a bug or did I mess something up?

Answer 1

I think you are encountering this C# compiler bug: https://connect.microsoft.com/VisualStudio/feedback/details/675205/c-compiler-performs-sign-extension-during-unsigned-pointer-arithmetic

Which was filed as a result of this question: 64-bit pointer arithmetic in C#, Check for arithmetic overflow changes behavior

Answer 2

(Answer under construction)

I checked the emitted x64 asm and these are my observations:

Base pointer:

data:
00000000024539E0

Pointer with correct carry:

data + (uint)0xFFFF0000:
00000001024439E0

Disassembly of the instructions:

    byte* ptr2 = data + ((uint)0xFFFF0000); // redundant cast to be extra sure
00000084  mov         ecx,0FFFF0000h 
00000089  mov         rax,qword ptr [rsp+20h] 
0000008e  add         rax,rcx 
00000091  mov         qword ptr [rsp+38h],rax 

Pointer with incorrect carry:

data + offset:
00000000024439E0

Disassembly of the instructions:

    uint offset = 0xFFFF0000;
0000006a  mov         dword ptr [rsp+28h],0FFFF0000h 
    byte* ptr1 = data + offset;
00000072  movsxd      rcx,dword ptr [rsp+28h] ; (1)
00000077  mov         rax,qword ptr [rsp+20h] 
0000007c  add         rax,rcx 
0000007f  mov         qword ptr [rsp+30h],rax 

The instruction (1) converts an unsigned int32 into a signed long with sign extension (bug or feature?). Therefore rcx contains 0xFFFFFFFFFFFF0000 , while it should contain 0x00000000FFFF0000 for the addition to work properly.

And according to 64 bit arithmetic:

0xFFFFFFFFFFFF0000 +
0x00000000024539E0 =
0x00000000024439E0

The add overflows indeed.

I don't know if this is a bug or intended behavior, I'm going to check SSCLI before trying to give any conclusion. EDIT: See Ben Voigt's answer.