setrecursionlimit

[Rustom Mody]

On Thursday, May 19, 2016 at 3:13:44 AM UTC+5:30, bream wrote:
> On Wednesday, May 18, 2016 at 6:47:42 PM UTC+1, Chris Kaynor wrote:
> > On Wed, May 18, 2016 at 10:15 AM, Steven D'Aprano wrote:
> > 
> > > I don't really understand why the system can't track the current top of the
> > > stack and bottom of the heap, and if they're going to collide, halt the
> > > process. That would still be kinda awful, in a sudden "your application
> > > just died" kind of way, but it would be better than "your computer is now
> > > owned by some hacker in Hong Kong, who is now renting it by the hour to
> > > some spammer in Texas".
> > >
> > 
> > Most modern OSs will track it, and kill the app (hence the exception/crash
> > that occurs), rather than allow access outside the memory. 
> > Chris
> 
> Oh so funny, I just had to roar with laughter, unless you (plural) classify VMS as a "modern OS".  Then of course some youngsters think the OS is simply software, whereas us old gits know that a combination of hardware and software makes for something that is rather more solid.

Hi Mark -- howdy!

Much truth in your comment.
Dijkstra pointed out (in mid-70s!) the essential tradeoff between hardware and
software. He did it for numeric oveflow but it applies equally for stack overflow.

In short software costs are variable costs: An instruction that is executed
a million times costs million-fold one that is executed only once.
For hardware its a fixed cost: Once the investment in silicon is done,
once or a billion times is the same.

Therefore -- and this is Dijkstra's key insight -- if a test is very skew,
ie if the if-part is 99.9% likely to be taken and the else part only 0.1%
the programmer will be increasingly tempted to drop the test and hope/pray that
the 0.1% does not happen.

With a hardware interrupt this temptation would be obviated.

Both the mess in catching numeric overflow as well as stackoverflow looks like
its C's fault. 
I consider it as the fault of currently fashionable stock hardware