Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <7769@brl-smoke.ARPA>
Date: 26 Apr 88 17:19:08 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <7750@brl-smoke.ARPA> <195@sdeggo.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <195@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes:
-Whether or not this was necessary I'm not sure, but it does seem 
-like the easiest way to implement it.  The stack is set at the top 
-of memory; when it grows to big it generates a segmentation violation 
-which causes malloc() to allocate more memory and relocate the stack 
-at the top of memory.  The other alternative, if implemented with 
-vanilla malloc, would be to give some memory to the stack and then 
-monitor it everytime something was put on the stack to make sure it 
-didn't overflow.  Relying on the system to tell you when you're
-out of space is a lot easier.

It also doesn't work right on some systems such as MC68000s.
Several of us spent a lot of time getting this fixed, and the BRL
version of the Bourne shell can be configured to take the tedious
but correct approach instead of relying on the SIGSEGV kludge.

I think it serves as a good illustration of what can go wrong with
preempting library routines rather than cooperating with them.