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!

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.

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.

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.

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.

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.