BL> Your demo is doing that intentionally, but you can do it
 BL> accidentally too. If you call part of a program within itself
 BL> recursively again and again, and use a new variable each time
 BL> (a large array, say) then you need stack space for that
 BL> variable each time, and you soon run over the 64K. If this
 BL> happens, you need to know how to get around it... by using the
 BL> heap instead, or re-using the same variable, or whatever.

 IS> Not to diminish your argument; deeply recursive calls with a
 IS> lot of parameters can certainly eat up stack space pretty
 IS> quickly. However, arrays (and other structures longer than 4
 IS> bytes, with the exception of reals) aren't passed on the stack
 IS> at all; even if not declared as VAR parameters, these are
 IS> passed as a pointer to the structure. Turbo then makes a local
 IS> copy for the current procedure's use, as covered in Chapter 18
 IS> of the TP6 Programmer's Guide. 

  It was a shorthand explanation; not a definitive text. It seemed to
me that the main problem was the thought that a larger stack made a 
program run better, and it that idea I tried to correct.

  And a large array *is* on the stack, along with 256-byte strings and 
the rest. Your words are just as inaccurate as mine.

Regards,
Bob

___ Blue Wave/QWK v2.12
@EOT:

---