Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxh.cso.uiuc.edu!unicorn
From: unicorn@uxh.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Turbo-C stack problem
Message-ID: <12300010@uxh.cso.uiuc.edu>
Date: 20 Jul 90 02:28:00 GMT
References: <141716@<90Jul19>
Lines: 35
Nf-ID: #R:<90Jul19:141716:uxh.cso.uiuc.edu:12300010:000:963
Nf-From: uxh.cso.uiuc.edu!unicorn    Jul 19 21:28:00 1990


Andy,

  I had a similiar problem once also, but I was able to reduce other memory
use so I didn't have to change the stack size.  This may totaly off-base,
but here is what i think is going on.

  The stack size is set by the program, not by the compiler.  The compiler
sets up the memory size and usage.  It only defines the top of the stack,
not the bottom.  The variable _stklen is used by the initiating code to
calculate the pointer where the end of stack is at.  So I think! that
it just needs something like,

#define STACKSIZE 10240

extern unsigned _stklen = STACKSIZE;

main()
{
.
.
.
}


  I never actually tried this, but it kind of makes sense (I hope!).
Since _stklen becomes a public symbol after compilation, the initiating
code can easily look at it in the data segment.

I hope that this helps (and works!!).  Let me know if you learn anything
else about this.

Harry E. Miller
unicorn@uxh.cso.uiuc.edu
Smile! - The Unicorn is watching you!!