Char to Int Pointer Casting Not Working

Question

I'm confusing about casting of char to int pointer. I'm checking how pointer's casting works and the below code int to char is working fine.

#include <iostream>
using namespace std;
int main(){
    int a=65;
    void *p=&a;
    cout << *static_cast<char*>(p);
}

Output

A

But when I try to cast from char to int it's not showing correct value.

#include <iostream>
using namespace std;
int main(){
    char a='A';
    void *p=&a;
    cout << *static_cast<int*>(p);

}

What is the problem in the above code? Output is about garbage value.

Answer 1

First, you have to understand that the x86 architecture is what is called little-endian. This means that in multibyte variables, the bytes are ordered in memory from least to most significant. If you don't understand what that means, it'll become clear in a second.

A char is 8 bits -- one byte. When you store 'A' into one, it gets the value 0x41 and is happy. An int is larger; on many architectures it is 32 bits -- 4 bytes. When you assign the value 'A' to an int, it gets the value 0x00000041. This is numerically exactly the same, but there are three extra bytes of zeros in the int.

So your int contains 0x00000041. In memory, that is arranged in bytes, and because you're on a little-endian architecture, those bytes are arranged from least to most significant -- the opposite of how we normally write them! The memory actually looks like this:

      +----+----+----+----+
int:  | 41 | 00 | 00 | 00 |
      +----+----+----+----+
      +----+
char: | 41 |
      +----+

When you take a pointer to the int and cast it to a char*, and then dereference it, the compiler will take the first byte of the int -- because chars are only one byte wide -- and print it out. The other three bytes get ignored! Now look back and notice that if the order of the bytes in the int were reversed, as on a big-endian architecture, you would have retrieved the value zero instead! So the behavior of this code -- the fact that the cast from int* to char* worked as you expected -- was strictly dependent on the machine you were running it on.

On the other hand, when you take a pointer to the char and cast it to an int*, and then defererence it, the compiler will grab the one byte in the char as you'd expect, but then it will also read three more bytes past it, because ints are four bytes wide! What is in those three bytes? You don't know! Your memory looks like this:

      +----+
char: | 41 |
      +----+
      +----+----+----+----+
int:  | 41 | ?? | ?? | ?? |
      +----+----+----+----+

You get a garbage value in your int because you're reading memory that is uninitialized. On a different platform or under a different planetary alignment, your code might work perfectly fine, or it might segfault and crash. There's no telling. This is what is known as undefined behavior, and it is a dangerous game that we play with our compilers. We have to be very careful when working with memory on like this; there's nothing scarier than nondeterministic code.

Answer 2

You can safely represent anything as an array of char. It doesn't work the other way. This is part of the STRICT ALIASING rule.

You can read up on strict aliasing in other questions: What is the strict aliasing rule?

More closely related to your question: Once again: strict aliasing rule and char*

Answer 3

Quoting the answer given here: What is the strict aliasing rule?

[...] dereferencing a pointer that aliases another of an incompatible type is undefined behavior. Unfortunately, you can still code this way, maybe get some warnings, have it compile fine, only to have weird unexpected behavior when you run the code.

Also related to your question: Once again: strict aliasing rule and char*

Both C and C++ allow accessing any object type via char * (or specifically, an lvalue of type char). They do not allow accessing a char object via an arbitrary type. So yes, the rule is a "one way" rule.

(I must give credit for this second link to @Let_Me_Be)

Answer 4

According to Standards, casting a char (or multiple chars) to int is undefined behavior and therefore any result is allowed. Most compilers will try to do what makes sense, and so the following is a likely reason for the behavior you are seeing on your specific architecture:

Assuming a 32 bit int, an int is the same size as 4 chars

Different architectures will treat those four bytes differently to translate their value to an int, most commonly this is either little endian or big endian

Looking at:

[Byte1][Byte2][Byte3][Byte4]

The int value would either be:

(Little Endina) Byte1+Byte2*256+Byte3*256^2+Byte4*256^3
(Big Endian   ) Byte4+Byte3*256+Byte2*256^2+Byte1*256^3

In your case either Byte1 or Byte4 is being set, the remaining bytes are whatever happens to be in memory since you are only reserving one byte where you need 4

Try the following:

int main(){
    char a[4]={'A', 0, 0, 0};
    void *p=a;
    cout << *static_cast<int*>(p);    
}

You may have to switch the initialization to {0,0,0, 'A'} to get what you want based on architecture

As noted, this is undefined behavior, but should work with most compilers and give you a better idea of what is going on under the hood

Answer 5

Here when you are doing:

cout << *static_cast<int*>(p);

you are actually saying that p is pointing to an integer (represented by 4 bytes in memory) but you just written a char in it before (represented by 1 bytes in memory) so when you cast it to an integer you expanded your variable to 3 garbage bytes.

But if you cast it back to a char you will get your 'A' because you are slicing your int to a char:

cout << (char) *static_cast<int*>(p);

Otherwise if you just want the ASCII value, cast your void* to an char* (so when you dereference it you are only accessing 1 byte) and cast what is inside it to int.

char a = 'A';
void *p=&a;
cout << static_cast<int>(*((char*)p));

The fact is that static cast is able to understand that you want to cast an char to int (and get his ASCII value) but when asking a char* to int* he just change the number of bytes read when you dereference it.

Answer 6

Consider following code:

#include <iostream>
#include <iomanip>
using namespace std;
int main(){
  {
    int a=65;
    cout << hex << static_cast<int>(a) << "\n";
    void *p=&a;
    cout << hex << setfill('0') << setw(2 * sizeof(int)) << *static_cast<int*>(p) << "\n";
  }

  {
    char a='A';
    cout << hex << static_cast<int>(a) << "\n";
    void *p=&a;
    cout << hex << *static_cast<int*>(p) << "\n";
  }
}

There is indeed 'A' character code (0x41) in the output, but its padded to the size of int with uninitialized values. You can see it, when you output the hexadecimal values of variables.