stack

@Kdo

The variables will be stored consecutively on the stack in the order that they are declared.

Is that accurate? I thought the compiler was free to rearrange allocations to prevent padding when possible. (Comp Org was a few years ago, and I wasn't the most attentive, so I may certainly be off-base!)

@kaufmed,

I don't know of a rule that requires the parameters to be on the stack in any given order.  That said, I'm not aware of any compiler rearranging the variables.  (They may exist.  I'd love to know.)  I have seen code that required the variables in declared order as the program used array overruns (instead of union/struct) to access adjacent items.

Kent

So the bottomline, there is no way to determine runtime the stack size due to compiler placement?

I don't know of a direct way.  You may be able to write some assembly code.

Or some odd trick like this:

int F (char *x)
{
  char Name[10];
  int x1, x2;
  float z;
  char buffer[100];

  if (x = =NULL)
    F(Name);
  else
    fprintf (stdout, "Stack entry is %d bytes\n", (int)(Name - x));
}

main ()
{
  F(NULL);
}

Use braces to control scope, which controls stack allocation. You can get the size of variable by using addresses. Example:

void func (void)
{
    int numStackBytes;
    {
         // declare a bunch of variables
        {
             int topOfStack;
             numStackBytes = (((char *) &topOfStack) - ((char *) &numStackBytes)) - sizeof (numStackBytes);
        }
    }
}

Select allOpen in new window

With this method it doesn't matter what order the compiler places the variables on the stack. Note that once you exit the innermost scope shown, topOfStack is out of scope and numStackBytes is still in scope.

You could also do this by writing some machine code to store the value of the stack pointer into a variable before and after the variables are allocated, but you still need to be certain of the scope. Be aware that on some processors, the stack grows downwards in memory.

I tried but it doesnt gave me correct stack size maybe the compiler is not placing the variables in continous memory location

Hi perl,

Can you post the test code and describe what you're seeing?  The rules are pretty simple (all local variables are going to be on the stack).  We just have to analyze what you're seeing.


Kent

Are you sure its wrong size? What size are expecting and what size are you getting? It seems unlikely that the compiler is not putting them contiguously, because they are pushed on to the stack.

Compiler does optimization. If you are not using a variable, compiler may ignore that. So address diff which ur looking mayn't be correct.

So initialize variables at the time of declaration. and then start your calculation logic.or you may use a print statement to access all the declared variables.

Is there something you wish to accomplish by computing the stack size?

I was debugging some crash and as thinking to add some debug statements by checking the stack size of the function to make sure I am not running out of stack limit and overwriting on some other functions stack space

Stack overflow is something that many/most run-time libraries check.

What compiler/environment are you using

Linux (CentOS)

Hi perl,

I doubt that you're getting a stack overflow.  You might be getting an overrun (the function accessing memory outside of it's current stack variables), but not an overflow (where the entire stack is used up).

I'm pretty sure that the stack on CentOS C runtime is hardware protected so that you can't read/write past the end.


Kent

The only way you are likely to get stack overflow is if the function allocates a large array locally and you call it recursively. A recursion loop is generally the only thing that causes the stack to overflow and most debuggers will catch that and allow you to see the problem.

I don't thin anyone does calculation of stack during runtime.Rather smartly define the variable and it's scope. Decide which is highly necessay to be define in large scope.

For a 16bit OS like in DOS, stack size is 1MB but it varies in 32bit OS.

On a 16-bit OS, the default stack size is likely to be about 8K.

@Kdo:Yes u r right. I forgot it. 1MB is the total memory that a program uses.

I agree Subrat2009,

I don't remember how i started in this stupid  direction of calculating stack size in between. crazy