CODEWITHSUNDEEP
cpointers
Zoneur
Zoneur

Reputation: 1099

Unexpected address output

I am trying to figure out how the addresses are assigned to variables located on the stack. I ran the little program below:

int main()
{
    long a;
    int b;
    int c;

    printf("&a = %p\n", &a);
    printf("&b = %p\n", &b);
    printf("&c = %p\n", &c);
}

The output I expected was (considering addresses are going down):

&a = 0x7fff6e1acb88
&b = 0x7fff6e1acb80
&c = 0x7fff6e1acb7c

But instead I got:

&a = 0x7fff6e1acb88
&b = 0x7fff6e1acb80
&c = 0x7fff6e1acb84

How come the c variable is located between the a and b variable? Are variables not put on the stack as they are declared?

I tried replacing the type of a from long to int and I got this:

&a = 0x7fff48466a74
&b = 0x7fff48466a78
&c = 0x7fff48466a7c

Here I don't understand why are the addresses going up, while they were going down previously?

I compiled the program using gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-11precise2), if that's of any help.

Upvotes: 6

Views: 194

Answers (6)

Kris
Kris

Reputation: 31

Agreeing with @Lundin that you cannot print the address of the registers these a most likely sitting in. The best thing you can do to see how these are stored would be to dump the object code and investigate what happens when you create more local variables then the amount of registers to hold them. That is when you'll see the stack activity (in the disassembly ).

$ gcc -c main.c -o main.o
$ objdump -D main.o > main.dump

Upvotes: 1

Arjun Sreedharan
Arjun Sreedharan

Reputation: 11453

The direction of stack growth depends on the architecture. On x86, stack grows down (from higher address to lower). How the variables are put on the stack also depends on the OS's Application binary interface (ABI) and how the compiler follows the ABI convention. But, the compiler may not necessarily follow the ABI conventions all the time.

Upvotes: 2

Anis_Stack
Anis_Stack

Reputation: 3452

it depends on the compiler. for example I test your code with "GNU GCC version 4.8.1" and the Compiler allocate all locale variables in order :

&a = 0x7fffe265d118
&b = 0x7fffe265d114
&c = 0x7fffe265d110

Upvotes: 1

Lundin
Lundin

Reputation: 213810

Even though the stack pointer is counting downwards on your given CPU, the program will be using stack frames. How a certain parameter is allocated inside the stack frame is implementation-defined.

Also note that some CPUs have up-counting stack pointers.

Also note that local variables are not necessarily allocated on the stack. More often, they are allocated in CPU registers. But when you take the address of a variable, you kind of force the compiler to allocate it on the stack, since registers have no addresses.

Upvotes: 5

elixenide
elixenide

Reputation: 44833

Variables are not necessarily put on the stack in the order in which they are declared. You can't predict where on the stack they will be -- they could be in any order. As glglgl pointed out in the comments, they don't even have to be on the stack and could simply be held in registers.

Upvotes: 5

Lee Duhem
Lee Duhem

Reputation: 15121

Are variables not put on the stack as they are declared?

No.

why are the addresses going up, while they were going down previously?

They could going up, but they do not have to.

Compilers is free to rearrage the order of local variables that it sees is fit, or it could even delete or add some.

Upvotes: 9

Related Questions