将指针强制转换为char指针会导致C中的数据丢失？

Question

I have the following piece of code:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
  int n = 260; 
  int *p = &n;
  char *pp = (char*)p;
  *pp = 0;

  printf("n = %d\n", n);
  system("PAUSE");  
  return 0;
}

The output put of the program is n = 256 . I may understand why it is, but I am not really sure. Can anyone give me a clear explanation, please?

Thanks a lot.

Answer 1

The int 260 (= 256 * 1 + 4) will look like this in memory - note that this depends on the endianness of the machine - also, this is for a 32-bit (4 byte) int :

0x04 0x01 0x00 0x00

By using a char pointer, you point to the first byte and change it to 0x00 , which changes the int to 256 (= 256 * 1 + 0).

Answer 2

You're apparently working on a little-endian machine. What's happening is that you're starting with an int that takes up at least two bytes. The value 260 is 256+4. The 256 goes in the second byte, and the 4 in the first byte. When you write 0 to the first byte, you're left with only the 256 in the second byte.

Answer 3

I understood what exactly happens by changing value:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
  int n = 260; 
  int *p = &n;
  char *pp = (char*)p;
  *pp = 20;

    printf("pp = %d\n", (int)*pp);
  printf("n = %d\n", (int)n);
  system("PAUSE");  
  return 0;
}

The output value are 20 and 276

So basically the problem is not that you have data loss, is that the char pointer points only to the first byte of the int and so it changes only that, the other bytes are not changed and that's why those weird value (if you are on an INTEL processor the first byte is the least significant, that's why you change the "smallest" part of the number

Answer 4

In C a pointer references a block of bytes based on the type associated with the pointer. So in your case the integer pointer refers to a block 4 bytes in size, while a char is only one byte long. When you set the char to 0 it only changes the first byte of the integer value, but because of how numbers are stored in memory on modern machines (effectively in reverse order from how you would write it) you are overwritting the least significant byte (which was 4) you are left w/ 256 as the value

Answer 5

Considering 32 bit systems, 256 will be represented in like this.

00000000 (Byte-3)   00000000 (Byte-2)    00000001(Byte-1)     00000100(Byte-0)

Now when p is typecast-ed to a char pointer, the label on the pointer changes, but the memory contents don't. It means earlier p could have access 4 bytes, as it was an integer pointer, but now it can only access 1 byte as it is a char pointer. So, only the LSB gets changes to zero, not all the 4 bytes.

And it becomes

00000000 (Byte-3)   00000000 (Byte-2)    00000001(Byte-1)     00000000(Byte-0)

Hence, the o/p is 256 .

Answer 6

Your problem is the assignment *pp = 0; You're dereferencing pp which points to n, and changing n. However, pp is a char pointer so it doesn't change all of n which is an int. This causes the binary complications in the other answers.

Answer 7

In terms of the C language, the description for what you are doing is modifying the representation of the int variable n . In C, all types have a "representation" as one or more bytes ( unsigned char ), and it's legal to access the underlying representation by casting a pointer to char * or unsigned char * - the latter is better for reasons that would just unnecessarily complicate things if I went into them here.

As schnaader answered, on a little endian, twos complement implementation with 32-bit int , the representation of 260 is:

0x04 0x01 0x00 0x00

and overwriting the first byte with 0 yields:

0x00 0x01 0x00 0x00

which is the representation for 256 on such an implementation.

C allows implementations which have padding bits and trap representations (which raise a signal/abort your program if they're accessed), so in general overwriting part but not all of an int in this way is not safe to do. Nonetheless, it does work on most real-world machines, and if you instead used the type uint32_t , it would be guaranteed to work (although the ordering of the bits would still be implementation-dependent).