addresses of variables

Discussion in 'C Programming' started by Zero, Mar 18, 2012.

  1. Zero

    Zero Guest

    hello

    does the ansi standard define
    at what addresses variables will be found or is this dependent on each compiler,
    I wonder, e.g.
    when I have this code
    main()
    {
    int a, b, c, d;
    char e;
    }

    whether those local variables are placed one after the other in memory (e.g. 0x100, 0x104, 0x108, 0x10C and 0x10D or
    whether the can be aligned at different addresses 0x200, 0x100, 0x300...

    Does the standard define those things...

    Zero
    Zero, Mar 18, 2012
    #1
    1. Advertising

  2. Zero

    BartC Guest

    "Zero" <> wrote in message
    news:9524023.127.1332068169176.JavaMail.geo-discussion-forums@ynbq18...

    > does the ansi standard define
    > at what addresses variables will be found or is this dependent on each
    > compiler,
    > I wonder, e.g.
    > when I have this code
    > main()
    > {
    > int a, b, c, d;
    > char e;
    > }
    >
    > whether those local variables are placed one after the other in memory
    > (e.g. 0x100, 0x104, 0x108, 0x10C and 0x10D or
    > whether the can be aligned at different addresses 0x200, 0x100, 0x300...
    >
    > Does the standard define those things...


    No.

    --
    Bartc
    BartC, Mar 18, 2012
    #2
    1. Advertising

  3. Zero <> wrote:
    > does the ansi standard define
    > at what addresses variables will be found or is this dependent on each compiler,
    > I wonder, e.g.
    > when I have this code
    > main()
    > {
    > int a, b, c, d;
    > char e;
    > }


    > whether those local variables are placed one after the other in memory (e.g. 0x100, 0x104, 0x108, 0x10C and 0x10D or
    > whether the can be aligned at different addresses 0x200, 0x100, 0x300...


    > Does the standard define those things...


    No, that's all up for the compiler to decide on its own. And the
    variables don't even need to have addresses: unless you take the
    address of a variable somewhere the compiler can very well "op-
    timize out" a variable by keeping its value in a CPU register
    or, if it finds it's not really needed, throw it out completely.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
    Jens Thoms Toerring, Mar 18, 2012
    #3
  4. Zero

    Zero Guest

    Thank you!
    Zero, Mar 18, 2012
    #4
  5. On 19-Mar-12 09:52, Lowell Gilbert wrote:
    > Zero <> writes:
    >> Thank you!

    >
    > Note, however, that by printing the addresses, that code may have
    > changed how the compiler would otherwise have stored the variables.


    The Uncertainty Principle applied to C? Good job!

    > This isn't just compiler-dependent; it tends to be very sensitive to
    > optimization, as well.


    Indeed; this is a very basic optimization. Any decent compiler will try
    to eliminate variables, where possible, and to store the ones it can't
    in registers. Taking the address of a variable, though, forces that
    variable to be stored in memory.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Mar 19, 2012
    #5
  6. Zero

    James Kuyper Guest

    On 03/19/2012 01:55 PM, Stephen Sprunk wrote:
    > On 19-Mar-12 09:52, Lowell Gilbert wrote:
    >> Zero <> writes:
    >>> Thank you!

    >>
    >> Note, however, that by printing the addresses, that code may have
    >> changed how the compiler would otherwise have stored the variables.

    >
    > The Uncertainty Principle applied to C? Good job!
    >
    >> This isn't just compiler-dependent; it tends to be very sensitive to
    >> optimization, as well.

    >
    > Indeed; this is a very basic optimization. Any decent compiler will try
    > to eliminate variables, where possible, and to store the ones it can't
    > in registers. Taking the address of a variable, though, forces that
    > variable to be stored in memory.


    Sort-of. Because of the as-if principle, &variable doesn't have to
    actually identify the location (if any) where the variable is stored
    unless some other part of the program would make the failure of the
    program to store it there detectable.

    For instance, if two non-overlapping objects have overlapping lifetimes,
    and the program prints out the values of pointers to those two objects,
    the print outs must identify different memory locations. If those
    addresses are compared for equality, they must compare unequal. If such
    a pointer is dereferenced, the behavior must be the same as if it
    actually pointed at the object it's supposed to refer to. However, if
    none of those things occur, printf("%p\n", (void*)&object) can print
    just about any arbitrary memory location that is not, detectably,
    currently in use for some other purpose, regardless of how (or whether)
    the variable is actually stored.
    James Kuyper, Mar 19, 2012
    #6
  7. Zero

    jacob navia Guest

    Le 19/03/12 19:30, James Kuyper a écrit :
    > On 03/19/2012 01:55 PM, Stephen Sprunk wrote:
    >> On 19-Mar-12 09:52, Lowell Gilbert wrote:
    >>> Zero<> writes:
    >>>> Thank you!
    >>>
    >>> Note, however, that by printing the addresses, that code may have
    >>> changed how the compiler would otherwise have stored the variables.

    >>
    >> The Uncertainty Principle applied to C? Good job!
    >>
    >>> This isn't just compiler-dependent; it tends to be very sensitive to
    >>> optimization, as well.

    >>
    >> Indeed; this is a very basic optimization. Any decent compiler will try
    >> to eliminate variables, where possible, and to store the ones it can't
    >> in registers. Taking the address of a variable, though, forces that
    >> variable to be stored in memory.

    >
    > Sort-of. Because of the as-if principle,&variable doesn't have to
    > actually identify the location (if any) where the variable is stored
    > unless some other part of the program would make the failure of the
    > program to store it there detectable.
    >
    > For instance, if two non-overlapping objects have overlapping lifetimes,
    > and the program prints out the values of pointers to those two objects,
    > the print outs must identify different memory locations. If those
    > addresses are compared for equality, they must compare unequal. If such
    > a pointer is dereferenced, the behavior must be the same as if it
    > actually pointed at the object it's supposed to refer to. However, if
    > none of those things occur, printf("%p\n", (void*)&object) can print
    > just about any arbitrary memory location that is not, detectably,
    > currently in use for some other purpose, regardless of how (or whether)
    > the variable is actually stored.


    I would rather avoid such compilers.

    The problem is that the compiler writer has NO idea what is going on
    and why the value of that variable is being printed.

    For instance

    void *p = list->next;
    #ifdef DEBUG
    printf("Next pointer is %p\n",p);
    #endif
    } // function end

    True, p is never used anywhere and the "as if" reasoning
    invoked by you is "right".

    The programmer however, wants to identify the faulty pointer
    and that address will help him figure out a bug!

    It is extremely dangerous when compilers start doing whatever
    they want instead of LIMITING themselves to COMPILE the code!

    jacob
    jacob navia, Mar 19, 2012
    #7
  8. Zero

    Guest


    > It is extremely dangerous when compilers start doing whatever
    > they want instead of LIMITING themselves to COMPILE the code!
    >
    > jacob


    Ah, clearly the words of someone who has never written a compiler.
    , Mar 19, 2012
    #8
  9. Zero

    James Kuyper Guest

    On 03/19/2012 03:17 PM, wrote:
    >
    >> It is extremely dangerous when compilers start doing whatever
    >> they want instead of LIMITING themselves to COMPILE the code!
    >>
    >> jacob

    >
    > Ah, clearly the words of someone who has never written a compiler.


    He has written a compiler, and I gather he's done a fairly good job of
    it. He knows immensely more about implementing a compiler than I do; but
    I know little bit more about what the standard permits than he does.
    Whether or not he's aware of the fact, he himself has made extensive use
    of the "doing whatever they want" option, when it applies (and sometimes
    when it does not) to implement a number of extensions to C - some fully
    conforming, others not so much.

    The standard permits things no reasonable implementation would ever do,
    and things a good implementation should never do. I'm not sure that this
    falls in either of those categories, though. Subject to the constraints
    I mentioned in my previous message, I'm not sure it matters much for any
    practical purpose what address is printed out. "Practical purposes"
    necessarily involve violating one of the restrictions I mentioned.

    For instance, if you print the address out to a file, and then read it
    back in, that's a different matter; the address you read back in must,
    if the object's lifetime has not yet ended, be dereferenceable and, when
    dereferenced, actually refer to the same object. The same applies with
    addresses that are displayed to the user, and then typed back in by the
    user. The fact that this is true interferes with what would otherwise be
    natural ways of implementing garbage collection for a conforming
    implementation of C.
    James Kuyper, Mar 19, 2012
    #9
  10. Zero

    Guest

    [stuff clipped]

    Ah well, maybe I miss understood -- Now, I'm thinking the statement was a joke.

    In any case, I hope no one took my statement badly.
    , Mar 19, 2012
    #10
  11. On 19-Mar-12 13:30, James Kuyper wrote:
    > On 03/19/2012 01:55 PM, Stephen Sprunk wrote:
    >> Indeed; this is a very basic optimization. Any decent compiler will try
    >> to eliminate variables, where possible, and to store the ones it can't
    >> in registers. Taking the address of a variable, though, forces that
    >> variable to be stored in memory.

    >
    > Sort-of. Because of the as-if principle, &variable doesn't have to
    > actually identify the location (if any) where the variable is stored
    > unless some other part of the program would make the failure of the
    > program to store it there detectable.
    >
    > For instance, if two non-overlapping objects have overlapping lifetimes,
    > and the program prints out the values of pointers to those two objects,
    > the print outs must identify different memory locations. If those
    > addresses are compared for equality, they must compare unequal. If such
    > a pointer is dereferenced, the behavior must be the same as if it
    > actually pointed at the object it's supposed to refer to. However, if
    > none of those things occur, printf("%p\n", (void*)&object) can print
    > just about any arbitrary memory location that is not, detectably,
    > currently in use for some other purpose, regardless of how (or whether)
    > the variable is actually stored.


    All of the above sounds reasonable, but when/why would any reasonably
    sane implementation (i.e. not the DS9k) take advantage of that dubious
    flexibility rather than use the "obvious" approach of storing the
    variable in memory?

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Mar 20, 2012
    #11
  12. Zero

    James Kuyper Guest

    On 03/20/2012 04:52 AM, Stephen Sprunk wrote:
    > On 19-Mar-12 13:30, James Kuyper wrote:

    ....
    >> Sort-of. Because of the as-if principle, &variable doesn't have to
    >> actually identify the location (if any) where the variable is stored
    >> unless some other part of the program would make the failure of the
    >> program to store it there detectable.
    >>
    >> For instance, if two non-overlapping objects have overlapping lifetimes,
    >> and the program prints out the values of pointers to those two objects,
    >> the print outs must identify different memory locations. If those
    >> addresses are compared for equality, they must compare unequal. If such
    >> a pointer is dereferenced, the behavior must be the same as if it
    >> actually pointed at the object it's supposed to refer to. However, if
    >> none of those things occur, printf("%p\n", (void*)&object) can print
    >> just about any arbitrary memory location that is not, detectably,
    >> currently in use for some other purpose, regardless of how (or whether)
    >> the variable is actually stored.

    >
    > All of the above sounds reasonable, but when/why would any reasonably
    > sane implementation (i.e. not the DS9k) take advantage of that dubious
    > flexibility rather than use the "obvious" approach of storing the
    > variable in memory?


    Storing the variable in memory takes memory space and time; why bother
    storing it there if you don't have to? A plausible implementation might
    reserve a piece of memory to store the value in, if it actually needs to
    be stored, and then find that it never actually needs to store the value
    there. &variable would return that address, but the object never actual
    resides in that memory. This doesn't sound like DS9K optimization to me.
    --
    James Kuyper
    James Kuyper, Mar 20, 2012
    #12
  13. James Kuyper <> writes:

    > Sort-of. Because of the as-if principle, &variable doesn't have to
    > actually identify the location (if any) where the variable is stored
    > unless some other part of the program would make the failure of the
    > program to store it there detectable.


    I know that I venture into the uncharted interiors of the vast tract
    of C known as "implementation defined"...

    But when I go there, I can tell you that I would be extremely upset,
    if I found that my friendly optimizing compiler gave me a bogus buffer
    address, even if the only usage thereof the compiler can detect, is to
    enter it into the struct that defines a DMA transfer.

    I would be doubly upset, if I found out that it only does this
    optimization once in while.

    --
    /Wegge

    Leder efter redundant peering af dk.*,linux.debian.*
    Anders Wegge Keller, Mar 20, 2012
    #13
  14. Zero

    James Kuyper Guest

    On 03/20/2012 03:02 PM, Anders Wegge Keller wrote:
    > James Kuyper <> writes:
    >
    >> Sort-of. Because of the as-if principle, &variable doesn't have to
    >> actually identify the location (if any) where the variable is stored
    >> unless some other part of the program would make the failure of the
    >> program to store it there detectable.

    >
    > I know that I venture into the uncharted interiors of the vast tract
    > of C known as "implementation defined"...
    >
    > But when I go there, I can tell you that I would be extremely upset,
    > if I found that my friendly optimizing compiler gave me a bogus buffer
    > address, even if the only usage thereof the compiler can detect, is to
    > enter it into the struct that defines a DMA transfer.


    DMA transfer is outside the scope of the C standard, so I didn't word my
    statement quite right to cover that possibility, but that basically
    falls under the category of "some other part of the program would make
    the failure of the program to store it there detectable".
    James Kuyper, Mar 20, 2012
    #14
  15. On 20-Mar-12 05:00, James Kuyper wrote:
    > On 03/20/2012 04:52 AM, Stephen Sprunk wrote:
    >> On 19-Mar-12 13:30, James Kuyper wrote:

    > ...
    >>> Sort-of. Because of the as-if principle, &variable doesn't have to
    >>> actually identify the location (if any) where the variable is stored
    >>> unless some other part of the program would make the failure of the
    >>> program to store it there detectable.
    >>>
    >>> For instance, if two non-overlapping objects have overlapping lifetimes,
    >>> and the program prints out the values of pointers to those two objects,
    >>> the print outs must identify different memory locations. If those
    >>> addresses are compared for equality, they must compare unequal. If such
    >>> a pointer is dereferenced, the behavior must be the same as if it
    >>> actually pointed at the object it's supposed to refer to. However, if
    >>> none of those things occur, printf("%p\n", (void*)&object) can print
    >>> just about any arbitrary memory location that is not, detectably,
    >>> currently in use for some other purpose, regardless of how (or whether)
    >>> the variable is actually stored.

    >>
    >> All of the above sounds reasonable, but when/why would any reasonably
    >> sane implementation (i.e. not the DS9k) take advantage of that dubious
    >> flexibility rather than use the "obvious" approach of storing the
    >> variable in memory?

    >
    > Storing the variable in memory takes memory space and time; why bother
    > storing it there if you don't have to? A plausible implementation might
    > reserve a piece of memory to store the value in, if it actually needs to
    > be stored, and then find that it never actually needs to store the value
    > there. &variable would return that address, but the object never actual
    > resides in that memory. This doesn't sound like DS9K optimization to me.


    Hmm. My mental model of how a compiler works is slightly different: the
    compiler initially locates all variables in memory and then (provided
    various conditions are met) migrates some of them to registers or
    eliminates them entirely. Taking the address of the variable would,
    logically, prohibit such migration or elimination. Allocating addresses
    for memory variables would be done (probably by the assembler) long
    after that took place. Allocating addresses for variables that were
    migrated or eliminated seems illogical.

    (Perhaps that model is too simplistic, and I welcome correction, but so
    far it has served me well enough to understand most optimizations.)

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Mar 20, 2012
    #15
  16. Zero

    James Kuyper Guest

    On 03/20/2012 05:47 PM, Stephen Sprunk wrote:
    > On 20-Mar-12 05:00, James Kuyper wrote:

    ....
    >> Storing the variable in memory takes memory space and time; why bother
    >> storing it there if you don't have to? A plausible implementation might
    >> reserve a piece of memory to store the value in, if it actually needs to
    >> be stored, and then find that it never actually needs to store the value
    >> there. &variable would return that address, but the object never actual
    >> resides in that memory. This doesn't sound like DS9K optimization to me.

    >
    > Hmm. My mental model of how a compiler works is slightly different: the
    > compiler initially locates all variables in memory and then (provided
    > various conditions are met) migrates some of them to registers or
    > eliminates them entirely. Taking the address of the variable would,
    > logically, prohibit such migration or elimination. ...


    The key point is that it is not the taking of the address that causes
    such prohibition - it is using the address, or allowing it to be passed
    somewhere where the compiler can't be sure it won't be used, that
    actually triggers the prohibition.

    > ... Allocating addresses
    > for memory variables would be done (probably by the assembler) long
    > after that took place. ...


    The actual numerical address might not be allocated until later, but the
    idea that an address might be needed can be recorded at an earlier stage
    in the process.

    > ... Allocating addresses for variables that were
    > migrated or eliminated seems illogical. ...


    So is code that takes an address without actually using it. But it's
    precisely such code that I'm discussing. I'm mainly concerned with
    whether or not such optimization is permitted, I'm less concerned with
    whether or not there's a plausible way in which a reasonably-designed
    implementation would produce such an optimization. But the key point is
    that taking the address is not the right trigger - it's what happens to
    that address that matters. If nothing "meaningful" happens to it, the
    address doesn't have to mean anything real, and actual storage of the
    value at the addressed location doesn't have to happen.
    James Kuyper, Mar 20, 2012
    #16
  17. James Kuyper <> writes:

    > On 03/20/2012 03:02 PM, Anders Wegge Keller wrote:


    >> I know that I venture into the uncharted interiors of the vast tract
    >> of C known as "implementation defined"...


    ...

    > DMA transfer is outside the scope of the C standard,


    I know, and I'm not trying to tell you otherwise.

    > so I didn't word my statement quite right to cover that possibility,
    > but that basically falls under the category of "some other part of
    > the program would make the failure of the program to store it there
    > detectable".


    That would cover it.

    --
    /Wegge

    Leder efter redundant peering af dk.*,linux.debian.*
    Anders Wegge Keller, Mar 21, 2012
    #17
  18. On 20-Mar-12 17:37, James Kuyper wrote:
    > On 03/20/2012 05:47 PM, Stephen Sprunk wrote:
    >> Hmm. My mental model of how a compiler works is slightly different: the
    >> compiler initially locates all variables in memory and then (provided
    >> various conditions are met) migrates some of them to registers or
    >> eliminates them entirely. Taking the address of the variable would,
    >> logically, prohibit such migration or elimination. ...

    >
    > The key point is that it is not the taking of the address that causes
    > such prohibition - it is using the address, or allowing it to be passed
    > somewhere where the compiler can't be sure it won't be used, that
    > actually triggers the prohibition.


    Of course.

    >> ... Allocating addresses for variables that were
    >> migrated or eliminated seems illogical. ...

    >
    > So is code that takes an address without actually using it. But it's
    > precisely such code that I'm discussing. I'm mainly concerned with
    > whether or not such optimization is permitted, I'm less concerned with
    > whether or not there's a plausible way in which a reasonably-designed
    > implementation would produce such an optimization. But the key point is
    > that taking the address is not the right trigger - it's what happens to
    > that address that matters. If nothing "meaningful" happens to it, the
    > address doesn't have to mean anything real, and actual storage of the
    > value at the addressed location doesn't have to happen.


    If nothing "meaningful" was done with the address, then presumably other
    optimizations would eliminate the code that generated it, thus allowing
    the compiler to migrate or eliminate the variable.

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Mar 21, 2012
    #18
  19. Zero

    James Kuyper Guest

    On 03/21/2012 06:58 PM, Stephen Sprunk wrote:
    > On 20-Mar-12 17:37, James Kuyper wrote:

    ....
    >> implementation would produce such an optimization. But the key point is
    >> that taking the address is not the right trigger - it's what happens to
    >> that address that matters. If nothing "meaningful" happens to it, the
    >> address doesn't have to mean anything real, and actual storage of the
    >> value at the addressed location doesn't have to happen.

    >
    > If nothing "meaningful" was done with the address, then presumably other
    > optimizations would eliminate the code that generated it, thus allowing
    > the compiler to migrate or eliminate the variable.


    I don't follow that - why would a situation that renders it unnecessary
    to store a variable in addressable memory imply that it's unnecessary to
    store it anywhere?
    --
    James Kuyper
    James Kuyper, Mar 22, 2012
    #19
  20. On 21-Mar-12 19:24, James Kuyper wrote:
    > On 03/21/2012 06:58 PM, Stephen Sprunk wrote:
    >> On 20-Mar-12 17:37, James Kuyper wrote:

    > ...
    >>> implementation would produce such an optimization. But the key point is
    >>> that taking the address is not the right trigger - it's what happens to
    >>> that address that matters. If nothing "meaningful" happens to it, the
    >>> address doesn't have to mean anything real, and actual storage of the
    >>> value at the addressed location doesn't have to happen.

    >>
    >> If nothing "meaningful" was done with the address, then presumably other
    >> optimizations would eliminate the code that generated it, thus allowing
    >> the compiler to migrate or eliminate the variable.

    >
    > I don't follow that - why would a situation that renders it unnecessary
    > to store a variable in addressable memory imply that it's unnecessary to
    > store it anywhere?


    Concrete example:

    int quux(void)
    {
    int foo = 42;
    int *bar = &foo;
    return foo;
    }

    1. Both foo and bar start out in memory.
    2. foo can't be migrated to a register because of the &foo.
    3. bar is eliminated via dead code elimination.
    4. foo can now be migrated to a register.
    5. No address is needed for either foo or bar.

    OTOH, say you have this:

    #include <stdio.h>
    int quux(void)
    {
    int foo = 42;
    int *bar = &foo;
    printf("%p\n", (void*)bar);
    return foo;
    }

    1. Both foo and bar start out in memory.
    2. foo can't be migrated to a register because of the &foo.
    3. bar is migrated to a register.
    4. An address is needed for foo but not for bar.

    Can you give a similar example for what you're describing--and your
    mental model of what a compiler would do with it?

    S

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
    Stephen Sprunk, Mar 22, 2012
    #20
    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. salman sheikh

    Best way to mux addresses

    salman sheikh, Jan 30, 2004, in forum: VHDL
    Replies:
    0
    Views:
    507
    salman sheikh
    Jan 30, 2004
  2. anonymous
    Replies:
    28
    Views:
    578
    anonymous
    Nov 29, 2005
  3. namespace1
    Replies:
    3
    Views:
    879
  4. Replies:
    9
    Views:
    924
  5. Casey Hawthorne
    Replies:
    3
    Views:
    1,064
    Flash Gordon
    Nov 1, 2009
Loading...

Share This Page