8

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!

codeObserver
  • 6,521
  • 16
  • 76
  • 121

5 Answers5

6

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.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • Wouldn't doing something like this `int a = 0; int b = &a;` force an ordering? (I'm taking the address of the variable to remove the possibility of it being optimized away.) – RedX May 21 '11 at 02:10
  • @RedX: Not at all. The order of initialization has nothing to do with the relative locations of the space allocated on the stack. – R.. GitHub STOP HELPING ICE May 21 '11 at 02:20
  • Also taking the address of `a` will not keep it from being optimized away if you never use that address for anything. By the way, `int b = &a;` is invalid C and will not compile. You'd need a cast. – R.. GitHub STOP HELPING ICE May 21 '11 at 02:20
5

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.

Grumdrig
  • 16,588
  • 14
  • 58
  • 69
4

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.

Community
  • 1
  • 1
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
4

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.

AProgrammer
  • 51,233
  • 8
  • 91
  • 143
  • +1 to prove it. Curious How were you so sure that this will be done ? All the literals of similar data-type are grouped together for some optimization ? – codeObserver May 21 '11 at 02:09
  • 1
    @p1. I wasn't sure it would have been done but I've spend enough time reordering struct fields in order to decrease memory consumption to known that if you want to respect alignment constraints and minimize the size of the stack frame, reordering is mandatory. – AProgrammer May 21 '11 at 02:14
3

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.

Dietrich Epp
  • 205,541
  • 37
  • 345
  • 415
  • The last sentence/para is not true. The compiler could inline the functions, in which case the above issue still applies. Ensuring that the compiler *must* create a new stack frame is actually very difficult. The best way I can think is using function pointers and clobbering the representation of the function pointer by xor'ing its bytes with a value obtained by a library call that will necessarily be zero, but where the compiler can have no way to prove it will be zero. – R.. GitHub STOP HELPING ICE May 21 '11 at 02:02
  • @R Correct, but it's easy to prevent a compiler from inlining functions. Making a function recursive is one way, using function attributes is another, defining them in separate translation units is a third. (None of these always work on all compilers, but still.) – Dietrich Epp May 21 '11 at 03:36