Problem 4242 You are to determine how big stacks can grow to

Problem 424-2:
You are to determine how big stacks can grow to be.

For part A, write C code that calls a single function with a large stack-allocated array, and see how big that array can be.

For part B, write C code that calls a function recursively, and see what the maximum recursion depth is.

For both parts A and B, what error message do you get when you overflow the stack? Do you get different results if you run on a different machine (different OS or different version of Linux)? Do you get different results compiling for the IA32 (\"-m32\") or for the x86-64 ISA (with \"-m64\")?
If you are running the bash shell (pretty common on Linux and Macs), you can find the default stack size (and other system information) by typing \"ulimit -a\". (If you are running the tcsh shell, there is a \"limit\" command that gives similar but not identical functionality.) Does the listed size agree with the results of your experiments? The \"ulimit\" command also allows you to set the stack size with the \"-s\" option. (You can readily find the details with an internet search.) Try your experiments again after increasing the stack size. Did it do what you expected? (If you can\'t get the ulimit/limit commands to work, make a note of this in your submission.)
Finally, try compiling with the \"-Os\" optimization flag for gcc. (It tells the compiler to optimize for size but not at the expense of speed.) See if this affects the recursion depth you observed for a given stack size.
The code here (link: http://ece324web.groups.et.byu.net/hw/code/stacksize.c ) is intended to serve as a starting point. Make sure you understand what it is doing if you use it. Note that it just tries sizes and recursion depths that are powers of two. You\'ll have to plug different values in for N and M to see where it breaks.

Solution

Solutions:

Part A: determining the stack size and results consistent for different operating systems and for both the IA32 and x86-64 we need to check both.

Codes are given below

#include <stdio.h>

#define N ???        /* plug something in here */
#define XSIZE (0x01<<N)

#define M ???        /* plug something in here */
#define MAXREC (0x01<<M)

double big_array(void)
{
    int i, x[XSIZE];
    double result = 0.0;
    for (i = 0; i < XSIZE; i++)
   x[i] = i;
    for (i = 0; i < XSIZE; i++)
   result += x[i];
    return result;
}

double max_recursion(int val)
{
    if (val <= 1)
   return 1;
    return val + max_recursion(val-1);
}

int main()
{
    printf(\"Result returned by big_array() is %e\ \", big_array());
    printf(\"Result returned by max_recursion() is %e\ \", max_recursion(MAXREC));
}

If our array is too large we can simply declare an array of sufficient size to handle our input that means if names are no longer than 25 characters, then you could safely declare name[26]. For strings, always need at minimum the number of chars to store + 1 for the null-terminating character.

If there may be a few characters more than 25, there\'s nothing wrong with declaring the array few bytes longer than needed to protect against accidental writing beyond the end of the array. array name[32].

To allocate the array on the stack, will need to reserve 32 megabytes of stack space first preferrably a bit more. For that, using Dev-C++ will either need to set the reserved stack size for your executable using compiler flags such as -Wl,--stack,34000000 this reserves somewhat more than 32MiB, or create a thread which lets specify a reserved stack size for that thread.But really, again, just don\'t do that. There\'s nothing wrong with allocating a huge array dynamically.

B)

}

The number of recursion levels can do depends on the call-stack size combined with the size of local variables and arguments that are placed on such a stack. Aside from \"how the code is written\", just like many other memory related things, this is very much dependent on the system running on, the compiler using, optimisation level [1], and so on. Doing recursion at unlimited depth is not a good idea, and whether that is acceptable in the system. There is unfortunately nothing anyone can do at the time stack runs out at best program crashes, at worst it doesn\'t, but instead causes something else to go wrong, such as the stack or heap of some other application gets messed up! On a desktop machine, it\'s acceptable to have a recursion depth of a hew hundred to some thousands, but not much more than this that is if you have small usage of stack in each call if each call is using up kilobytes of stack, should limit the call level even further, or reduce the need for stack-space.