pointer addresses

Discussion in 'C Programming' started by Bill Cunningham, May 6, 2014.

  1. From a previous thread I was corrected in my syntax. My tutorial
    demonstrates the address of pointers and pointees. I don't know if it's the
    address they hold or their virtual address as assigned by kernel services
    under the hood. But here's corrected code and a warning from my compiler.

    #include <stdio.h>

    int main()
    {
    int *p;
    int a = 15;
    p = &a;
    printf("%p\n", (void *) &a);
    printf("%p\n", (void *) a);
    }

    Very simple. I believethis is what I was told is correct now for compiler
    stderr output.

    p.c: In function 'main':
    p.c:9:20: warning: cast to pointer from integer of different size
    [-Wint-to-pointer-cast]

    :Shrug:
     
    Bill Cunningham, May 6, 2014
    #1
    1. Advertisements

  2. Bill Cunningham

    Lew Pitcher Guest

    No, Bill
    Yes, Bill

    Take a look at the line
    printf("%p\n", (void *) a);

    What is "a"? Can it be a pointer?

    Never mind the "(void *)". That's just you forcing the compiler to treat "a"
    as a pointer to void. But, as I asked before, what is "a"? Is it a pointer
    that can be cast to void *?
     
    Lew Pitcher, May 6, 2014
    #2
    1. Advertisements

  3. Bill Cunningham

    John Gordon Guest

    You're printing the address of a as a pointer. All well and good.
    You're printing the VALUE of a as a pointer. What the heck?!
     
    John Gordon, May 6, 2014
    #3
  4. Sorry slight mistake! Change that to p. Here I changed it!

    #include <stdio.h>

    int main()
    {
    int *p;
    int a = 15;
    p = &a;
    printf("%p\n", (void *) &p);
    printf("%p\n", (void *) p);
    }

    Ok no errors. I notice each time I run this of course a different address is
    given but in so many bytes of what a pointer is supposed to be from a
    pointee.

    Bill
     
    Bill Cunningham, May 6, 2014
    #4
  5. Made a mistake Made a mistake! I do that sometimes! Check the new post.
    Whew
     
    Bill Cunningham, May 6, 2014
    #5
  6. Sorry Lew that is of course supposed to be a p! Ok... Well that cast I
    am told is the "proper" way to write this snippet of code. Now my tutorials
    are showing a good example of something here though. With the right code and
    using a p you see that there is exactly so much space between &p and p. The
    pointee and the pointer. Somewhere in the machine is an address that
    contains an int and the value 15.

    Bill
     
    Bill Cunningham, May 6, 2014
    #6
  7. There is no "supposed to be" difference between two different scalar
    objects or two objects not part of the same aggregate. Once the
    program is compiled, the layout of the automatic variables is set. No
    matter how many different times you run it, the two objects will
    always be the same number of bytes apart.

    What happens if you recompile the program with different options,
    especially optimization differences? What happens if you throw in
    another couple of variables? What happens if you reorder the
    definition of the variables in your source code?

    Given your problems with basic C concepts, this is an observation you
    should be ignoring. Any program that depends on a particular
    relationship between independent variables is plowing through
    undefined behavior.
     
    Barry Schwarz, May 6, 2014
    #7
  8. Just noticing something my new book is telling me. And it IS right. And
    you ADMITed it. Well that's just about how far I've gotten with it now.

    Bill
     
    Bill Cunningham, May 6, 2014
    #8
  9. Now isn't that cast of a void * supposesd to prevent any "undefined
    behavior"?

    Bill
     
    Bill Cunningham, May 6, 2014
    #9
  10. Historically a lot of C code did cast between pointers and integers.
    On most machines, addresses and integers are actually the same at
    machine level. But not all. If a pointer is segment:eek:ffset, then it's
    hard to say what casting an integer to a pointer is supposed to mean.

    Some machines trap when an invalid address is loaded into an address
    register. So declaring a void * with an invalid address could cause
    the trap. Which leads to the question, if you're going to print out
    the pointer, presumably something is wrong with it and you want to
    examine it. So how do you do so, if the call to printf() is going to
    trap?
     
    Malcolm McLean, May 7, 2014
    #10
  11. (snip)
    For 16 bit x86, with segment:eek:ffset 16 bit each, and 16 bit int,
    then assignment to int would get (I believe) only the offset.
    You have to assign to 32 bit long to get segment and offset.

    I am not sure about the Watcom compilers which also allowed
    for large model 32 bit (16 bit segment selector, 32 bit offset).
    As well as I remember, they didn't have a 64 bit (long long).
    If you have an illegal pointer in memory, you should be able to
    copy it, for example with memcpy, to an array of unsigned char.

    Note that JVM does not allow one to examine the bits of object
    reference variables.

    -- glen
     
    glen herrmannsfeldt, May 7, 2014
    #11
  12. Bill Cunningham

    Tonton Th Guest

    Tonton Th, May 7, 2014
    #12
  13. Bill Cunningham

    Tonton Th Guest

    Thinking that it was that all the time is an human brain
    undefined behavior.
     
    Tonton Th, May 7, 2014
    #13
  14. To me, this was a dead give-away: https://groups.google.com/d/msg/comp.lang.c/ZcxjoD1R9rs/PyAjZROoVUAJ

    He knows the cryptic name of the C standard (I assume it is the one that is current/latest?), he uses lmgtfy to be patronizing, and it is a response to Jacob who has a question about the rationale behind discrepancy between similar functions.

    Certainly not from someone who has a learning impediment due to side-effects of medication.

    - Anand
     
    Anand Hariharan, May 7, 2014
    #14
  15. That doesn't prove (or disprove) anything. Knowing about lmgtfy is
    unremarkable. N1570 is the latest public draft of the C standard;
    it's cited here on a regular basis. The response says nothing
    about how well he understands the question jacob was asking --
    except that the *rationale* for any such descrepancy is unlikely
    to be found in the standard.
     
    Keith Thompson, May 7, 2014
    #15
  16. Bill Cunningham

    Kaz Kylheku Guest

    Beyond a shadow of a doubt, like a mathematical theorem? No.

    Anand has presented very strong evidence.
    For a non-retard, yes.
     
    Kaz Kylheku, May 8, 2014
    #16
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.