CODEWITHSUNDEEP
c++cstacklow-level
codeObserver
codeObserver

Reputation: 6647

Why is a function call, rather than variable addresses, used to detect stack growth direction?

I read different responses to the question of detecting stack growth detection and I understand that, in modern architectures, stack might grow randomly, might be created off heap, and so on.

However, in this classic interview question, I want to understand why people use a function call rather than comparing 2 local variables in the same function. I think there must be some particular reason for doing this but, not being a C/low level developer [Java :)], I am simply guessing.

Here is the code I tried:

void sub (int *a)  {
    int b;
    int c;
    printf ("a:%d\n", a);
    printf ("b:%d\n", &b);
    printf ("c:%d\n", &c);
    if (&b > a) {
        printf ("Stack grows up.\n");
    } else {
        printf ("Stack grows down.\n");
    }
}

int main (void) {
    int a;
    int b;
    sub (&a);
    printf ("\nHere we go again!!\n");
    if (&b > &a)  {
        printf ("Stack grows up.\n");
    } else  {
        printf ("Stack grows down.\n");
    }
    return 0;
}

I also found this article which tries to optimize the solution which I don't understand either: http://www.devx.com/tips/Tip/37412

P.S: From different responses to this and other threads, it seems like the question itself is flawed/irrelevant, as an interview question it probably re-enforces incorrect assumptions unless someone researches the answer !

Thanks!

Upvotes: 8

Views: 762

Answers (5)

paxdiablo
paxdiablo

Reputation: 882226

Within a single stack frame, the compiler is free to order the local variables as it sees fit, so the code:

int i;
double j;

may have i before or after j. As long as the compile generates the correct code to access the variable, it can go anywhere.

In fact, unless you use the address-of operator & (or otherwise have to get at the address), the variable may never even be on the stack. It may be stored in a register for the duration of the call.

However, the order in which the stack frames themselves are put are restricted since, if they're out of order, function returns won't work that well (to put it mildly).

I should mention, of course, that the direction of stack growth is useful only in a very limited number of scenarios. The vast majority of code should never care about it. If you're interested in different architectures and how they handle stacks, see this answer.

Upvotes: 4

AProgrammer
AProgrammer

Reputation: 52314

Compilers may and do reorder variables in stack frames:

#include <stdio.h>

int main ()
{
    char c1;
    int a;
    char c2;
    int b;

    printf("%p %p %p %p\n", &c1, &a, &c2, &b);
    return 0;
}

print 

0x7ffff62acc1f 0x7ffff62acc18 0x7ffff62acc1e 0x7ffff62acc14

here (using gcc 4.4.3 on a 64 bits Linux). c2 has been moved next to c1.

Upvotes: 4

Dietrich Epp
Dietrich Epp

Reputation: 213648

The problem is that when you do this:

void test(void)
{
    int a;
    int b;
    if (&a < &b)
        ...

The result you get has nothing to do with the stack growth direction. The only way you know which way the stack grows is by creating new frames. The compiler is free to put a above b, or a below b as it sees fit. Different compilers may give different results.

However, if you call another function, that function's local variables have to be in a new stack frame, i.e., in the direction of growth from the caller's variables.

Upvotes: 3

Grumdrig
Grumdrig

Reputation: 16975

The order that declared variables will be placed on the stack is undefined, but in a function called by a function, the inner function call's arguments will necessarily be pushed on the stack later than the outer function's.

Upvotes: 5

Ignacio Vazquez-Abrams
Ignacio Vazquez-Abrams

Reputation: 799200

You can't fully control the order the compiler chooses to allocate the local variables in. You can however reasonably control the functions that will be called, and in what order.

Upvotes: 6

Related Questions