addresses of variables

[Zero]

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

 

[BartC]

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.

 

[Jens Thoms Toerring]

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

 

[Zero]

Thank you!

 

[Stephen Sprunk]

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

 

[James Kuyper]

The Uncertainty Principle applied to C? Good job!


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.

 

[jacob navia]

Le 19/03/12 19:30, James Kuyper a écrit :

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

 

[hoganlong]

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.

 

[James Kuyper]

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.

 

[hoganlong]

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

 

[Stephen Sprunk]

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

 

[James Kuyper]

On 19-Mar-12 13:30, James Kuyper wrote: ....

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.

 

[Anders Wegge Keller]

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.

 

[James Kuyper]

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

 

[Stephen Sprunk]

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

 

[James Kuyper]

On 20-Mar-12 05:00, James Kuyper 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.

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

 

[Anders Wegge Keller]

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

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.

 

[Stephen Sprunk]

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.

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

 

[James Kuyper]

On 20-Mar-12 17:37, James Kuyper wrote: ....

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?

 

[Stephen Sprunk]

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