test void pointer before cast (instanceof)

This is a discussion on test void pointer before cast (instanceof) within the C Programming forums, part of the General Programming Boards category; Hi All I've written the following test program Code: #include <stdio.h> int main(void) { char *c = "boss" ; void ...

  1. #1
    Registered User
    Join Date
    May 2009
    Posts
    72

    test void pointer before cast (instanceof)

    Hi All

    I've written the following test program

    Code:
    #include <stdio.h>
    
    int main(void) {
      char *c = "boss" ;
      void * d = (void *)c ;
    
      int *e ;
      e = (int *)d ;
      printf("%d char=%d int=%d\n", e, sizeof(char), sizeof(int)) ;
    }
    It prints: 8183 char=1 int=4

    What does 8183 mean. It seems that the 4 chars fit into one int, so I would guess there might be a relation between 8183 and "boss". Can this cast be useful ?

    But what if you don't know the original type of a void pointer, is there a way to determine it?

    Thnx a lot!
    LuCa

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    8183 is (apparently) the memory address where your read-only (probably) string was stored, printed as though it were an integer.

  3. #3
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    But what if you don't know the original type of a void pointer, is there a way to determine it?
    Not really. I suppose you could look at the memory address and get some idea of the alignment of whatever it is you're pointing at, but all that will let you do is guess. With a void* pointer, all you have is a memory address. That's it.

    What does 8183 mean.
    I suppose it's the value stored in e, which is the value in d, which was the value in c. This, in the end, is the location in memory of the string literal "boss". Note that string literals are embedded directly in the executable, which is why "8183" is such a low number (executables are loaded into low memory). If it was the address of a variable, e.g.
    Code:
    int x;
    printf("%p\n", &x);  /* %p -> print a pointer address, sort of like %x */);
    then you'd probably get a much higher number.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    The low number is probably because the original poster is using some ancient 16-bit compiler like Turbo C.

    --
    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
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    You're probably right.

    I assumed it was due to the text/whatever section being located in low memory, but that doesn't seem to be the case with my test code. The Turbo C explanation makes more sense. [edit] Notice the (void*) cast, too . . . . [/edit]
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  6. #6
    Registered User
    Join Date
    May 2009
    Posts
    72
    My compiler:
    Code:
    $ gcc --version
    i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
    Copyright (C) 2005 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    Not really. I suppose you could look at the memory address and get some idea of the alignment of whatever it is you're pointing at, but all that will let you do is guess. With a void* pointer, all you have is a memory address. That's it.
    What does that mean: the alignment of whatever it is you're pointing at ?
    Can you give an example or a link to documentation ?

    LuCa

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Alignment is what byte boundary the address matches. An odd address has an alignment of 1, if the address is even, it has at least 2 as alignment. Integers will naturally be aligned at 4 byte boundaries. A 64-bit integer or a double float will align to a 8 byte boundary, etc.

    But just because something is aligned to 8 bytes doesn't MEAN that it is a double. In fact, it's perfectly possible in some architectures to store data unaligned - it just means that the processor will have to do extra work to read the data from memory.

    There is really no way to know from the address itself (which is what a void * contains) what the data is. Only whatever created the data knows what it actually represents. I may for example store 0x3F800000 in an integer. But print it as a floating point value and it becomes 1.0 - so it looks like a plausible floating point number.

    --
    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.

  8. #8
    Registered User
    Join Date
    May 2009
    Posts
    72
    OK, thnx!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. sorting number
    By Leslie in forum C Programming
    Replies: 8
    Last Post: 05-20-2009, 04:23 AM
  2. Replies: 3
    Last Post: 05-13-2007, 08:55 AM
  3. Replies: 28
    Last Post: 07-16-2006, 11:35 PM
  4. msvc just ate one of my source files
    By Eber Kain in forum C++ Programming
    Replies: 6
    Last Post: 07-01-2004, 05:40 AM
  5. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 09:33 AM

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