Link to home
Start Free TrialLog in
Avatar of kishj
kishj

asked on

Borland C++ compiler, Stack issues/question

This is related to Borland 5.02 C++ compiler for an OWL program.

Someone I work with noticed this occurring for large variable:
owlclass::routine1()
{
  if (x)
  {
  call routine2()
  }
  else
  {
  averylargevariable1[1000]
  }
}
owlclass::routine2()
{
averylargevariable2[1000]
}

When x was true and they stepped into routine2() the stack blew up, BUT (Here is the weird part)
if the size of averylargevariable1[1000] was changed to [2], the program worked fine.
It appears that the space for averylargevariable1[1000] was being allocated even though the curley braces were not currently being entered which, I believe is a C++ standards no - no for the compiler.

Maybe something weird is happening with the optimizer or something?

Can anyone make any pertinent comments here, or suggestions? It just seems like some weird compiler behavior . The work around was to put the code and allocation in the curley brackets around averylargevariable1[1000] in its own set of curley braces.

Thanks
Jeff
ASKER CERTIFIED SOLUTION
Avatar of nietod
nietod

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of nietod
nietod

>> The work around was to put the code
>> and allocation in the curley brackets around
>> averylargevariable1[1000] in its own set of
>> curley braces.
But that work-around didn't work, right?  Its a "not work-around" right?

One solution is to expand your program's stack space.  There is likely to be a linker option for this

Another solution is to use dynamically allocated memory (new).  This memory will come from the heap, not the stack, so you won't get a stack overflow.  (You could run out of heap space, but that is less likely, the heap is usually much larger than the stack.)

Another option is to use an array class, like vector<>.  This is sort of a combination of the two approaches, the vector is local and gives you the conveneince of a local variable, but the array storage space comes from the heap and has a better chance of being allocated.
This might be due to the fact that in C calling convention the caller has to set up and pop the stack (for var args functionality) for the called function.
Sort of, its more due to the way the stack frame is created.  The stack frame is the portion of the stack used to store the locals.  This portion is not necessarily the top of the stack (it is the top when the function starts, but not necessarily the top later.)  so it can't be exapanded at will as new variables come into the scope.
Avatar of kishj

ASKER

I'll have to check the standard, but Thanks! This is good information.

I am fighting the battle of when we want to take the hit.

Jeff