🚀 go-pugleaf

On Wed, 6 Jun 2018 16:58:25 -0400, Peter Flass <peter...@yahoo.com> wrote:
>Questor <usenet@only.tnx> wrote:
>> On Mon, 04 Jun 2018 09:19:42 -0400, Dan Espen <dan1...@gmail.com> wrote:
>>> Peter Flass <peter...@yahoo.com> writes:
>>>> Gareth's Downstairs Computer
>>>> <headstone255.but.n...@yahoo.com> wrote:
>>>>> On 03/06/2018 22:40, Peter Flass wrote:
>>>>>> 
>>>>>> Some problems are easily solved by recursion that are significantly more
>>>>>> complicated otherwise.
>>>>> 
>>>>> I would be interested to know some examples, please?
>>>> 
>>>> Depth-first search of a binary tree. Top-down parsing.
>>>> 
>>>> Anything that requires retracing a path thru a data structure. Without
>>>> recursion you have to maintain a table to keep track of where you've been
>>>> and where you're going. Recursion just handles it naturally.
>>> 
>>> Yes, but using a table, the application has some way of detecting
>>> running out of storage.  For example, if the table depth is
>>> exceeded, the application can attempt to allocate a larger table
>>> and then fail with a message when storage is exceeded.
>>> With recursion, you eventually run out of storage but with
>>> any language I am familiar with it your program just dies.
>> 
>> DEC hardware can trap stack overflows (and underflows).  That facility doesn't
>> always make it into HLLs, nor the ability to do something about them.
>
>It's the doing something that's a problem. OS/2 used a "guard page" on the
>stack (hardware trap). You could set it to trap on accesses to the bottom
>page or so of the stack, so when the stack was *almost* used up you got
>notified, in time to do something. Once the stack is full, it's too late.

If you were serious about attempting to recover from a stack overflow, the first
thing the trap routine would do is exchange the stack pointer for a new one
pointing to sufficient pre-allocated stack space to attempt obtaining more
memory for a bigger stack and/or saving important information and exiting
gracefully.

You might do this in a language like BLISS or C, and of course assembly.  Not
so much in FORTRAN or COBOL.

Usually in the course of program development, one gets a sense of how much
stack space is required for normal operation.  Subsequent overflows or
underflows are probably the result of a programming error uncovered by an
obscure condition not encountered during testing.