question about pointers, unsigned int, and array

[-EquinoX-]

So say I have the code below:

int unsigned int i = 255;
char *op = (char *) &i;

so i is an unsigned int, how is it possible to convert it into a char pointer, which means that that pointer points to a char.. is the int converted to a char directly?? Thanks

[matsp]

In your case, you are converting the address of an unsigned integer to a char pointer. So you are converting a "unsigned int *" to a "char *".

--
Mats

[tabstop]

(1) You can't do "int unsigned int i"; just "unsigned int i".
(2) We are not converting i -- we are taking the memory address of i (using &i), and assigning it to op. Since op expects a pointer to a character, we cast it. This does not convert i in any way, shape, or form. (Accessing i through op is sort-of, kind-of possible; *op will interpret the first byte of i, which is probably 00000000, as a character (\0). But op will not know that the original variable was four bytes long (or whatever sizeof (int) is on your system).)

[matsp]

Accessing i through op is sort-of, kind-of possible; *op will interpret the first byte of i, which is probably 00000000, as a character (\0)..)

Or 255 if it's a little endian machine [which is likely, as PC's are by far the commonest machines around].

--
Mats

[-EquinoX-]

so when I read **op (which is the starting address) it will still be an int?

[-EquinoX-]

if it's a big endian machine then it would be 0 0 0 255 ?? and one more thing why is the first byte 0?? an unsigned int has 4 bytes in my machine

[tabstop]

Or 255 if it's a little endian machine [which is likely, as PC's are by far the commonest machines around].

--
Mats

You can tell how often I deal with hardware, since I always get that backward


**op is a syntax error. *op will take the first byte of i, and interpret it as a character. (It's either 0, which is \0, or 255 which is -1 (and so probably EOF, or some other not-valid character) if char is signed and ... something else if char is unsigned.)

[matsp]

No *op is the starting address. **op is invalid dereference, as *op is a char, not a pointer.

If we split a 32-bit integer with the value 255 into bytes, it becomes (biggest portion first) 0, 0, 0, 255 - the processor either stores "biggest first" (big endian) or "littlest first" (little endian).

I'm not sure I answered your question, but I think I did.

--
Mats

[-EquinoX-]

oh yeah sorry **op will just get the value at op and interpret it as a pointer to another address, although it's not right??

so why is 255 represented as 0 0 0 255 not 0 255 0 0 or 0 0 255 0?? why is it at the end?

[-EquinoX-]

can you explain this process:

If we split a 32-bit integer with the value 255 into bytes

[tabstop]

can you explain this process:

If we split a 32-bit integer with the value 255 into bytes

Well, write 255 in binary:
11111111
No, we need 32-bits, so pad with zeroes:
00000000000000000000000011111111
Bytes are 8-bits long:
00000000 00000000 00000000 11111111
and there you are.

Typically bytes are stored in order, high->low or low->high, rather than something like 1423 (although there's no engineering reason why not).

[-EquinoX-]

oh okay I got it! thanks

[matsp]

A byte is 8 bits. An unsigned int consisting of 4 bytes is 32 bits.
The value in binary is (bit 31 this end) 00000000 00000000 00000000 11111111 (bit zero this end).
As you see in this, the grouping is 8 bits, so in a shorter form, that would be 0, 0, 0, 255

The processor has no obligation at all to store these in any sensible form, it could store the 32 bits in the order
31, 0, 12, 14, 8, 9, 27, ... But it would be almost impossible for a human to read the number from the memory that way, and there is no benefit in any way shape or form for doing this.

Most processors work with bytes or multiples of bytes, and stores bits in the order of 0..7, 8..15, 16..23, 24..31 or 24..31, 16..23, 8..15, 0..7. Which it does depends on the actual processor implementations. PC processors use "little endian". Some "important" processors that use "big endian" are Sparc, 68000. Some processors actually have a switch to "change the processor between little endian and big endian".

--
Mats

[Elysia]

The whole reason this "magic" works is because in the computer architecture, there's no difference between char, int, float or whatever. It's all bits and bytes.
So what happens is that data is stored in a certain way (as "raw" data), and is interpreted depending on the type of variable you're using.
A float 1.0f is not 1 if you read it as integer, for example.
It's fun to mess around with pointers like this, but it's error prone and not portable, so it's suggested to avoid doing it in "serious" or "real" projects.
Otherwise, if you're just curious, then carry on.