question about pointers, unsigned int, and array

This is a discussion on question about pointers, unsigned int, and array within the C Programming forums, part of the General Programming Boards category; So say I have the code below: Code: int unsigned int i = 255; char *op = (char *) &i; ...

  1. #1
    Registered User
    Join Date
    Jan 2008
    Posts
    569

    question about pointers, unsigned int, and array

    So say I have the code below:

    Code:
    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

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    (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).)

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by tabstop View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Jan 2008
    Posts
    569
    so when I read **op (which is the starting address) it will still be an int?

  6. #6
    Registered User
    Join Date
    Jan 2008
    Posts
    569
    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
    Last edited by -EquinoX-; 03-12-2008 at 09:55 AM.

  7. #7
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by matsp View Post
    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.)

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Jan 2008
    Posts
    569
    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?

  10. #10
    Registered User
    Join Date
    Jan 2008
    Posts
    569
    can you explain this process:

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

  11. #11
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    Quote Originally Posted by -EquinoX- View Post
    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).

  12. #12
    Registered User
    Join Date
    Jan 2008
    Posts
    569
    oh okay I got it! thanks

  13. #13
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,545
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 48
    Last Post: 09-26-2008, 03:45 AM
  2. Need Help Please
    By YouShallNotPass in forum C++ Programming
    Replies: 3
    Last Post: 08-22-2006, 11:22 AM
  3. Replies: 2
    Last Post: 03-24-2006, 07:36 PM
  4. Replies: 4
    Last Post: 11-23-2003, 06:15 AM
  5. Hi, could someone help me with arrays?
    By goodn in forum C Programming
    Replies: 20
    Last Post: 10-18-2001, 09:48 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21