连续声明的变量的内存地址顺序是否总是在下降？

Question

why does the hexadecimal value of pointer address returned is always in decreasing order? for example here int a was declared before int d , so it's address always comes out to be greater than d , and same for &b , &e and &c , &f , I want to know that is this a fixed behavior or is this compiler dependent? I am using gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-1 )

#include<stdio.h>

int main(void){
    int a=1;
    int d=1;
    char b='a' ;
    char e='a';
    float c=1.0;
    float f=1.0;
    printf("a=%p\nd=%p\nb=%p\ne=%p\nc=%p\nf=%p\n",&a,&d,&b,&e,&c,&f);
   if (&a>&d)
        printf("&a>&d\n");
    else
    {printf("&a<&d");
    }
   if (&a>&d && &b>&e && &c>&f)
       printf("addresses are in descending order");
   else{
       printf("false");
   }

  return 0;

}

output:

a=0xbfc6bd98         //a>d
d=0xbfc6bd94         
b=0xbfc6bd9f         //b>e
e=0xbfc6bd9e
c=0xbfc6bd90         //c>f
f=0xbfc6bd8c
&a>&d 
addresses are in descending order

PS: I am new to c

Answer 1

Found this nicely explained in Smashing The Stack For Fun And Profit, by Aleph One . Extracted the most relevant parts.

---

  /------------------\\ lower | | memory | Text | addresses | | |------------------| | (Initialized) | | Data | | (Uninitialized) | |------------------| | | | Stack | higher | | memory \\------------------/ addresses Fig. 1 Process Memory Regions 

[...]

  The stack consists of logical stack frames that are pushed when calling a function and popped when returning. A stack frame contains the parameters to a function, its local variables, and the data necessary to recover the previous stack frame, including the value of the instruction pointer at the time of the function call. Depending on the implementation the stack will either grow down (towards lower memory addresses), or up. In our examples we'll use a stack that grows down. This is the way the stack grows on many computers including the Intel, Motorola, SPARC and MIPS processors. 

[...]

  Let us see what the stack looks like in a simple example: example1.c: ------------------------------------------------------------------------------ void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; } void main() { function(1,2,3); } ------------------------------------------------------------------------------ 

[...]

 With that in mind our stack looks like this when function() is called (each space represents a byte): bottom of top of memory memory buffer2 buffer1 sfp ret abc <------ [ ][ ][ ][ ][ ][ ][ ] top of bottom of stack stack 

---

As you can see, new (local) variables are pushed on top of the stack. Depending on the design of the architecture the stack grows towards higher memory addresses or towards lower memory addresses, the latter in your case.

From the viewpoint of the C language specification the order of memory locations of subsequently allocated variables is unspecified. Therefore, it depends ...

Answer 2

You can't make any assumptions about this. With some compilers, some architectures and some compiler switches you may see ths behaviour, ie local variables being allocated at successively lower stack addresses, but optimisation and other factors can change this behaviour.

Answer 3

The variables whose address you are comparing are all local variables allocated on stack. Now the way a stack grows (upwards or downwards) depends on the architecture. Looks like in your case the stack is growing downwards, so you are seeing decreasing addresses.

More on this here

Answer 4

很多ABI定义了一个向下增长的堆栈。

Answer 5

A gross and semi-accurate explanation (disregarding details about differences with stacks and heaps) is: You want to minimize the statically allocated stuff in memory colliding with the stuff you need to allocate dynamically. The dynamic stuff typically grows in size when your program runs. To maximize the capacity of allocating dynamic stuff, the static stuff and dynamic stuff are typically allocated at opposite ends of your memory space, with the dynamic stuff growing towards your static stuff. In your specific situation it looks like your compiler loads the static stuff low in memory and grows the dynamic stuff from the end towards the beginning of your memory (in the direction of your static stuff).