Re: This puzzled me

Discussion in 'C Programming' started by Keith Thompson, Sep 20, 2009.

  1. Mr John FO Evans <> writes:
    > If I have a structure s and a pointer p to that structure then
    >
    > value of s.element will be p->element
    >
    > However I needed the address of that element so which should I use?
    >
    > p.element (Not tried)
    > or
    > &p->element (Currently using this)
    > or
    > or &(p->element) (This dosn't work - Norcroft ARM C compiler)


    Either
    &p->element
    or
    &(p->element)
    should work.

    "This doesn't work" is one of the least useful things you can tell us.
    What *exactly* doesn't work, and *how* exactly doesn't it work?

    The following program compiles and runs without error on my system,
    and shows the same address three times. If it doesn't, there's
    something wrong with your compiler. (If you have a freestanding
    / embedded implementaton that doesn't support printf, adjust the
    program as needed.)

    #include <stdio.h>
    int main(void)
    {
    struct foo { int element; };
    struct foo s;
    struct foo *p = &s;
    printf("&s.element = %p\n", (void*)&s.element);
    printf("&p->element = %p\n", (void*)&p->element);
    printf("&(p->element) = %p\n", (void*)&(p->element));
    return 0;
    }

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 20, 2009
    #1
    1. Advertising

  2. Keith Thompson

    James Kuyper Guest

    Mr John FO Evans wrote:
    > In article <>, Keith Thompson <>
    > wrote:
    >>> If I have a structure s and a pointer p to that structure then
    >>>
    >>> value of s.element will be p->element
    >>>
    >>> However I needed the address of that element so which should I use?
    >>>
    >>> p.element (Not tried)
    >>> or
    >>> &p->element (Currently using this)
    >>> or
    >>> or &(p->element) (This dosn't work - Norcroft ARM C compiler)

    >> Either
    >> &p->element
    >> or
    >> &(p->element)
    >> should work.
    >>
    >> "This doesn't work" is one of the least useful things you can tell us.
    >> What *exactly* doesn't work, and *how* exactly doesn't it work?

    >
    > It returned a very low address.


    Do you know that this low address was an incorrect address? If so, how?
    In particular, what did you do to determine that it was a low address?
    There's a number of commonly made mistakes when people try to determine
    what address a pointer points at.

    >> The following program compiles and runs without error on my system,
    >> and shows the same address three times. If it doesn't, there's
    >> something wrong with your compiler.

    >
    >> #include <stdio.h>
    >> int main(void)
    >> {
    >> struct foo { int element; };
    >> struct foo s;
    >> struct foo *p = &s;
    >> printf("&s.element = %p\n", (void*)&s.element);
    >> printf("&p->element = %p\n", (void*)&p->element);
    >> printf("&(p->element) = %p\n", (void*)&(p->element));
    >> return 0;
    >> }

    >
    > This code also runs correctly giving three identical results even when
    > (*void) was replaced with (int) .


    I hope you replaced %p with with %d when you made that change?
    Note, there's no guarantee that converting a pointer to an int gives you
    any useful information about the pointer. If you convert to intptr_t,
    you've got a better chance of getting a meaningful result, but it's
    still not guaranteed.

    > NB The overall code is used to transfer addresses of the full range of
    > variable types in a main program into an embedded C - the type of the result
    > is less important since it is reconstructed.


    You're deep into implementation-specific territory if you are
    transferring memory addresses of objects that are part of one program to
    a different program. About the only thing that you are guaranteed to be
    able to do is transfer those, without modification, back to the original
    program for use there. Even that is guaranteed to work only if the
    program is still running - if it has been stopped and re-started, the
    addresses could, in principle, be quite different.
     
    James Kuyper, Sep 21, 2009
    #2
    1. Advertising

  3. Mr John FO Evans <> writes:
    > In article <h97o8v$8v1$-september.org>, James Kuyper
    > <> wrote:
    >> You're deep into implementation-specific territory if you are
    >> transferring memory addresses of objects that are part of one program to
    >> a different program. About the only thing that you are guaranteed to be
    >> able to do is transfer those, without modification, back to the original
    >> program for use there. Even that is guaranteed to work only if the
    >> program is still running - if it has been stopped and re-started, the
    >> addresses could, in principle, be quite different.

    >
    > Sorry I should have been more specific and not used the word programs - the
    > two 'parts' are compiled together as a single program and the overall
    > program is run continuously.
    >
    > There is a difference between &p.element and &(p.element) which I detected
    > a) due to numerical errors downstream and b) using debugging software.
    > However the structure declarations are remote from this code and there may
    > be subtle errors in the way the pointers are passed down. The simpler test
    > suggested by Keith Thompson does not show any errors.
    >
    > My personal guess is that &(p.element) has picked up the address of an
    > intermediate variable or register.


    There is no difference, in C, between &p.element and &(p.element).

    Either there's a bug in your compiler, or the difference you're seeing
    is caused by something else. It's likely that you're doing something
    that invokes undefined behavior. Without seeing actual code that
    exhibits the problem, we can only guess.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Sep 21, 2009
    #3
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Andrew

    VHDL: puzzled beginner

    Mark Andrew, Jun 27, 2004, in forum: VHDL
    Replies:
    5
    Views:
    651
    Mark Andrew
    Jun 30, 2004
  2. Daniel

    still puzzled

    Daniel, Jun 8, 2004, in forum: ASP .Net
    Replies:
    11
    Views:
    663
    Steven Cheng[MSFT]
    Jun 9, 2004
  3. schiefaw

    Very Puzzled, Please Help

    schiefaw, Jul 22, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    388
    schiefaw
    Jul 22, 2005
  4. Replies:
    5
    Views:
    1,410
  5. EvelynAnd Ethan
    Replies:
    4
    Views:
    998
    =?Utf-8?B?Sko=?=
    Jan 9, 2006
Loading...

Share This Page