When exactly is stack allocated [duplicate]

问题

Even in C (not just C++) you can declare variables at the start of a code block, which is enclosed in curly braces.

Example:

#include <stdio.h>
void use_stack(int cnt)
{
    if (cnt<=16) {
        int a[16];
        int i;
        a[0]=3;
        a[1]=5;
        for (i=2;i<cnt;i++) {
            a[i]=a[i-1]+a[i-2];
        }
        printf("a[%d] == %d\n",cnt-1,a[cnt-1]);
    }
    else {
        printf("cnt is too big\n");
    }
}

Now I know that variables like the array a[16] are allocated on the stack in this case.

I was wondering if the space for this array is allocated at the start of the function (first opening curly brace) or at the start of the block where it is declared (opening curly brace after if).

From examining the assembler code it seems the compiler allocates the space for a[16] directly at the entry of the function.

I actually expected that the stack would be allocated (stack pointer decreased) at the declaration of a[16] and that the stack would be de-allocated (stack pointer increased) at the end of the corresponding if code block.

But this does not happen it seems (stack for a[16] is allocated directly at function entry, even if a[16] is not used in the else branch).

Has anyone an explanation why this is the case ?

So is there any part of the C language standard, which explains this behavior, or does it have to do with things like "longjmp" or signal handling, which maybe require that the stack pointer is "constant" inside a function ?

Note: The reason why I assumed the stack would be allocated/deallocated at the start/end of the code block is, because in C++ the constructor/destructor of objects allocated on the stack will be called at the start/end of the code block. So if you examine the assembler code of a C++ program you will notice that the stack is still allocated at the function entry; just the constructor/destructor call will be done at the start/end of the code block.

I am explicitly interested why stack is not allocated/deallocated at the start/end of a code block using curly braces.

The question: At what exact moment is a local variable allocated storage? is only about a local variable allocated at the start of a function. I am surprised that stack allocation for variables allocated later inside a code block is also done at the function entry.

So far the answers have been:

Something to do with optimization
Might different for C, C++
Stack is not even mentioned in the C language specification

So: I am interested in the answer for C... (and I strongly believe that the answer will apply to C++ also, but I am not asking about C++ :-)).

Optimization: Here is an example which will directly demonstrate why I am so surprised and why I am quite sure that this is not an optimization:

#include <stdio.h>

static char *stackA;
static char *stackB;

static void calc(int c,int *array)
{
    int result;
    if (c<=0) {
        // base case c<=0:
        stackB=(char *)(&result);
        printf("stack ptr calc() = %p\n",stackB);
        if (array==NULL) {
            printf("a[0] == 1\n");
        } else {
            array[0]=1;
        }
        return;
    }

    // here: c>0
    if (array==NULL) {
        // no array allocated, so allocate it now
        int i;
        int a[2500];

        // calculate array entries recursively
        calc(c-1,a);

        // calculate current array entry a[c]
        a[c]=a[c-1]+3;

        // print full array
        for(i=0;i<=c;i++) {
            printf("a[%d] = %d\n",i,a[i]);
        }
    } else {
        // array already allocated
        calc(c-1,array);

        // calculate current array entry a[c]
        array[c]=array[c-1]+3;
    }
}

int main()
{
    int a;
    stackA=(char *)(&a);
    printf("stack ptr main() = %p\n",stackA);
    calc(9,NULL);
    printf("used stack = %d\n",(int)(stackA-stackB));
}

I am aware that this is an ugly program :-).

The function calc calculates n*3 + 1 for all 0<=n<=c in a recursive fashion.

If you look at the code for calc you notice that the array a[2500] is only declared when the input parameter array to the function is NULL.

Now this only happens in the call to calc which is done in main.

The stackA and stackB pointers are used to calculate a rough estimate how much stack is used by this program.

Now: int a[2500] should consume around 10000 bytes (4 bytes per integer, 2500 entries). So you could expect that the whole program consumes around 10000 bytes of stack + something additional (for overhead when calc is called recursively).

But: It turns out this program consumes around 100000 bytes of stack (10 times as much as expected). The reason is, that for each call of calc the array a[2500] is allocated, even if it is only used in the first call. There are 10 calls to calc (0<=c<=9) and so you consume 100000 bytes of stack.

It does not matter if you compile the program with or without optimization
GCC-4.8.4 and clang for x64, MS Visual C++ 2010, Windriver for DIAB (for PowerPC) all exhibit this behavior

Even weirder: C99 introduces Variable Length Arrays. If I replace int a[2500]; in the above code with int a[2500+c]; then the program uses less stack space (around 90000 bytes less).

Note: If I only change the call to calc in main to calc(1000,NULL); the program will crash (stack overflow == segmentation fault). If I additionally change to int a[2500+c]; the program works and uses less than 100KB stack. I still would like to see an answer, which explains why a Variable Length Array does not lead to a stack overflow whereas a fixed length array does lead to a stack overflow, in particular since this fixed length array is out of scope (except for the first invocation of calc).

So what's the reason for this behavior in C ?

I do not believe that GCC/clang both simply are not able to do better; I strongly believe there has to be a technical reason for this. Any ideas ?

Answer by Google

After more googling: I strongly believe this has something to do with "setjmp/longjmp" behavior. Google for "Variable Length Array longjmp" and see for yourself. It seems longjmp is hard to implement if you do not allocate all arrays at function entry.

回答1:

The language rules for automatic storage only guarantees that the last allocated is the first deallocated.

A compiler can implement this logical stack any way it sees fit.

If it can prove that a function isn't recursive it can even allocated the storage at program start-up.

I believe that the above applies to C as well as C++, but I'm no C expert.

Please, when you ask about the details of a programming language, limit the question to one language at a time.

回答2:

There is no technical reason for this other than choices that compiler makers made. It's less generated code and faster executing code to always reserve all the stack space we'll need at the beginning of the function. So all the compilers made the same reasonable performance tradeoff.

Try using a variable length array and you'll see that the compiler is fully capable of generating code that "allocates" stack just for a block. Something like this:

void
foo(int sz, int x)
{
        extern void bar(char *);
        if (x) {
                char a[sz];
                bar(a);
        } else {
                char a[10];
                bar(a);
        }
}

My compiler generates code that always reserves stack space for the x is false part, but the space for the true part is only reserved if x is true.

回答3:

How this is done isn't regulated by any standard. The C and C++ standards don't mention the stack at all, in theory those languages could be used even on computers that don't have a stack.

On computers that do have a stack, how this is done is specified by the ABI of the given system. Often, stack space is reserved at the point when the program enters the function. But compilers are free to optimize the code so that the stack space is only reserved when a certain variable is used.

At any rate, the point where you declare the variable has no relation to when it gets allocated. In your example, int a[16] is either allocated when the function is entered, or it is allocated just before the first place where it is used. It doesn't matter if a is declared inside the if statement or at the top of the function.

In C++ however, there is the concept of constructors. If your variable is an object with a constructor, then that constructor will get executed at the point where the variable is declared. Meaning that the variable must be allocated before that happens.

回答4:

Alf has explained the limitations and freedoms that the standard specifies (or rather, what it doesn't specify).

I'll suggest an answer to the question

why stack is not allocated/deallocated at the start/end of a code block using curly braces.

The compilers that you tested chose to do so (I'm actually just guessing, I didn't write any of them), because of better run-time performance and simplicity (and of course, because it is allowed).

Allocating 96 bytes (arbitrary example) once takes about half as much time as allocating 48 bytes twice. And third as much times as allocating 32 bytes thrice.

Consider a loop as an extreme case:

for(int i = 0; i < 1000000; i++) {
    int j;
}

If j is allocated at the start of the function, there is one allocation. If j is allocated within the loop body, then there will be a million allocations. Less allocations is better (faster).

Note: The reason why I assumed the stack would be allocated/deallocated at the start/end of the code block is, because in C++ the constructor/destructor of objects allocated on the stack will be called at the start/end of the code block.

Now you know that you were wrong to have assumed so. As written in a fine answer in the linked question, the allocation/dealocation need not coincide with the construction/destruction.

Imagine I would use a[100000]

That is approaching a very significant fraction of total stack space. You should allocate large blocks of memory like that dynamically.

来源：https://stackoverflow.com/questions/40974056/when-exactly-is-stack-allocated

标签

c++

stack