🚀 go-pugleaf

In article <1992Oct5.162337.238@genghis.borland.com> pete@genghis.borland.com (Pete Becker) writes:
>>Very true.  Borland compilers default to a 4K stack ... which may not
>>necessarily be enough (like the man said, it depends on your application,
>>the number of recursive calls you make, the number (i.e. space) of local
>>variables in your routines (not statics, automatics), and the depth your
>>routines go.
>
>	The stack is located at the top of the data segment.  Static data is
>at the bottom, and in small data models, the heap grows upward from the top of
>the static data.  You will not get a stack overflow unless you have stack
>checking turned on and the stack collides with the heap or with the static
>data.

You should say which compilers you're talking about - that's not the case 
with any of your Pascal compilers, for example.  TP's memory model is as 
follows, starting from low addresses and going up:

  code
  (new segment)
  static data
  global data
  (new segment)
  copro emulator data
  stack
  (new segment)
  heap

It's possible to corrupt your stack by misaddressing static or global data,
but not your code.  Similarly, bad stack references or stack overflows can 
only corrupt your coprocessor emulator or the heap, and bad offsets on heap 
references can't hurt anything but other parts of the heap (though bad 
segments can trash anything).  The positions of the segment boundaries are 
fixed at compile/link time (there's not much difference in TP).

TPW has an uglier memory model for Windows compatibility; I can't remember
all the details of it.

Duncan Murdoch
dmurdoch@mast.queensu.ca