🚀 go-pugleaf

usenet@only.tnx (Questor) writes:
>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.

e.g. sigaltstack for catching SIGSEGV.

>
>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.
>