# Thread: int to char (What happen to the excess data)?

1. ## int to char (What happen to the excess data)?

When copying an int into a char variable, how is any excess data used?

I know that an int is 4 bytes and a char is 1 byte.

So there will be an extra 3 bytes unused.

2. Technically, it is undefined. Moving values that are OUTSIDE THE RANGE of the destination type is "undefined behaviour" by the C standard - the compiler (or generated code) can do whatever it likes in that situation - perform whatever operation makes sense, launch nuclear attack on country X, crash the computer, etc, etc.

If you do not aspire for super-portable code, we can however, with realistic likelyhood of no nuclear attacks etc, make the assumption that it is simply "lost" - the data that doesn't fit in the destination will be ignored.

E.g. 256 into a char will be 0 [assuming 8 bits per char]. 812 [again, with 8 bits] will give you the value 44, or ',' if the character set is ASCII.

--
Mats

3. Look at this example in big-endian:

10001001 | 10111001 | 10000001 | 00110111 (32-bit integer, 2310635831 in decimal)

(10001001 | 10111001 | 10000001) 00110111 (8-bit char, 55 in decimal)

The bits in parentheses are sent to Nirwana since they don't fit into one byte. Of course, such low-level things may vary. That's why it's undefined. In little-endian, just reverse the order of bytes. It will do the same. In these cases, it's just like module 256. But don't rely on that - there are some other possibilities.

4. Obviously endian-ness doesn't matter for a simple assignment where the left-hand side is smaller than the right-hand side. If we are using pointers, then endian-ness WILL matter.

--
Mats

5. Then the remaining bits are still there, but not used. Although you can use them with a cast to int *.

6. Originally Posted by Brafil
Then the remaining bits are still there, but not used. Although you can use them with a cast to int *.
No, the remaining bits are not there. Most likely, they were not copied over, and thus are lost.

8. The compiler will likely warn you of "lost data" or something to that effect if the programmer does no explicit casting.

The source and destinations should be the same size... and the programmer should cast things to that effect to alleviate the compiler warnings - so as to prove he/she knows what they're doing on purpose. You may very well want to truncate excess data.

I seriously doubt that any implementation of C would grab some non intuitive byte out of a multi-byte integer when forcing into a char. Sheesh. We sure have a lot of "ANSI Standard blah blah" people here. What are you?? On a committee, or are ya programmers? Undefined... gimme a break.

9. Originally Posted by nonoob
We sure have a lot of "ANSI Standard blah blah" people here. What are you?? On a committee, or are ya programmers? Undefined... gimme a break.
The question should be "are ya programmers, or are ya lazy stupid programmers". People conform to the Standard for a reason.

Quzah.