Unexpected extension of pointer sign int32 or 32bit when converting to uint64

Question

I compiled this code using Visual Studio 2010 ( cl.exe /W4 ) as a C file:

 int main( int argc, char *argv[] ) { unsigned __int64 a = 0x00000000FFFFFFFF; void *orig = (void *)0xFFFFFFFF; unsigned __int64 b = (unsigned __int64)orig; if( a != b ) printf( " problem\ta: %016I64X\tb: %016I64X\n", a, b ); return; } 

There are no warnings, and the result:

problem a: 00000000FFFFFFFFFF b: FFFFFFFFFFFFFFFFF

I believe that int orig = (int)0xFFFFFFFF will be less controversial since I do not assign a pointer to an integer. However, the result will be the same.

Can someone explain to me where in the C standard this is covered by the fact that orig is an icon expanded from 0xFFFFFFFF to 0xFFFFFFFFFFFFFFFF?

I assumed that (unsigned __int64)orig would become 0x00000000FFFFFFFFFF. It looks like the conversion is the first for a signed type __int64, and then it becomes unsigned?

EDIT: This question was answered that pointers are extended, so I see this behavior in gcc and msvc. However, I do not understand why, when I do something like (unsigned __int64)(int)0xF0000000 , it subscribes to 0xFFFFFFFFF0000000, but (unsigned __int64)0xF0000000 instead does not show what I want, i.e. 0x00000000F0000000.

EDIT: response to the above change. The reason that (unsigned __int64)(int)0xF0000000 is a sign extension is because, as user R noted:

Converting a signed type (or any type) to an unsigned type always occurs by decreasing modulus plus plus the maximum value of the destination type.

And in (unsigned __int64)0xF0000000 0xF0000000 starts as an (unsigned __int64)0xF0000000 integer type, because it cannot fit into an integer type. Then the unsigned unsigned __int64 type will be converted.

So from this I have a function returning a 32-bit or 64-bit pointer as unsigned __int64 for comparison. I must first convert the 32-bit pointer in my 32-bit application to unsigned type before unsigned __int64 . The resulting code looks like this (but, you know, better):

 unsigned __int64 functionidontcontrol( char * ); unsigned __int64 x; void *y = thisisa32bitaddress; x = functionidontcontrol(str); if( x != (uintptr_t)y ) 

EDIT again: Here's what I found in the C99 standard: 6.3.1.3 Integer and unsigned integers

• 1 When a value with an integer type is converted to another integer type other than _Bool, if the value can be represented by a new type, it has not changed.
• 2 Otherwise, if the new type is unsigned, the value is converted to repeatedly adding or subtracting one greater than the maximum value that can be represented in the new type until the value is in the range of the new type .49)
• 3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is determined by the implementation or the signal determined by the implementation.
• 49) Rules describe arithmetic by mathematical value, not the value of this type of expression.

Answer 1

Converting a pointer to / from the whole is determined by the implementation.

Here , as gcc does, i.e. it is signed if the integer type is larger than the type of the pointer (this will happen regardless of the integer, signed or unsigned, just because gcc decided to implement it).

Msvc presumably behaves similarly. Change, the closest thing I can find on MSDN is this / this , assuming that converting 32-bit pointers to 64-bit pointers also extends.

Answer 2

From standard C99 (§6.3.2.3 / 6):

Any type of pointer can be converted to an integer type. Except as noted above, the result is determined by implementation . If the result cannot be represented in an integer type, the behavior is undefined. The result should not be in the range of values ​​of any integer type.

So, you need to find compiler documentation that talks about this.

Answer 3

Integer constants (for example, 0x00000000FFFFFFFF ) by default are signed integers and, therefore, can experience sign expansion when assigning a 64-bit variable. Try replacing the value in line 3 with:

 0x00000000FFFFFFFFULL 

Answer 4

Use this to avoid expanding the sign:

 unsigned __int64 a = 0x00000000FFFFFFFFLL; 

Note the L at the end. Without it, it is interpreted as a 32-bit signed number (-1) and then executed.