debian@debian:~$ cat /tmp/test.c
#include<stdio.h>
int main(void)
{
int m=1;
printf("m=%d\n",&m);
printf("m=%p\n",&m);
}
debian@debian:~$ gcc /tmp/test.c -o /tmp/test.exe
debian@debian:~$ /tmp/test.exe
m=-1078061268
m=0xbfbe172c
debian@debian:~$ python
Python 2.7.3 (default, Jan 2 2013, 16:53:07)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print hex(-1078061268)
-0x4041e8d4
why the -1078061268
in dec is not equal 0xbfbe172c
in hex?
it is. in 2's complement.
>>> hex(2**32-1078061268)
'0xbfbe172c'
An address is not an int. if your machine is 32bit, it is an unsigned int (in fact, uint32_t
). if not, it is a uint64_t
. it is always safe to put it in a uintptr_t
, and print it with %p
.
They are the same, you're comparing signed to unsigned.
take a look here at the formats.
#include<stdio.h>
int main(void)
{
int m=1;
printf("m=%u\n",&m); // 3219008780
printf("m=%p\n",&m); // 0xbfde2d0c
}
The first printf statement is treating the address as a signed integer. The second is treating it is a pointer (which, for printf, amounts to printing it out as an unsigned hex number). Those two numbers have the same binary representation in two's complement arithmetic, although they are not numerically equal. This is why comparisons between signed and unsigned values are a bad idea.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.