Re: Borland compiler query

matthew gream (mgream@nospam.heckle.ee.uts.EDU.AU)
Mon, 13 May 1996 13:06:16 +1000

Hi Josh!

`Joshua Graham Pitcher' wrote:

> A funny thing happened to me this morning. The following code caused my
> computer to crash when compiled under TC++3.0, BC++4.0 and BC++4.5:

Probably wasn't funny at the time :-).

> #define FFT_SIZE 4096
...
> float input_waveform[FFT_SIZE];
...

> However when I changed the input_waveform definition to a static (shifting
> it from the stack to global memory space IMHO) the problem was fixed.

Yup.

> Obviously it is crazy to put 4k arrays on the stack on a PC, but I was
> under the impression that my friendly borland compiler would tell me that it
> did not have the space to hold this array, instead of just crashing.

The default stack size is 4K for borland (in words, I presume), but
remember that your floats are double word sized --> i.e. taking up 4*32bit
= 8KWords stack, or 16kBytes memory.

> Can anyone shed some light on this? Just for the record I tried compiling
> the code under all available memory models.

Stack size is the same, irrespective of model :-). Most DOS compilers
use the "_stklen" variable to let you specify an alterate size (e.g.
something like 'extern int _stklen = 8192;'). It's a DOS thang, let's
save the architectural arguments that can flow from this, please :-).

Also, you can generally enable a "stack check" option, that places logic
at function entry points to look for stack overflows ... which will check
stack depth given local auto variable sizes: not sure on full semantics of
this one, check compiler's help stuff.

Generally, if something is biggish, then malloc/free are the best
mechanisms (new/delete for c++'ers) to avoid potential stack problems.

cheers,
m@nospam.ie.

ps. It probably doesn't crash until you actually write to the variable,
or subsequent variables declared after it. On function entry, space is
reserved for the variable (well, not even reserved, offsets are
computed, basically), but it isn't initialised (unless explicitly done
so by an assignment). Then, it can depend upon what's sitting next to
the stack segment: it may be part of the data segment, separate,
sitting next to unused memory, etc. Wierdo stack problems can be very
subtle! -- depending upon architecture :-).

--
Matthew Gream <m.gream@nospam.uts.edu.au> (work: matthewg@nospam.jtec.com.au)