Date:	Mon, 13 Dec 1999 10:28:06 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Martin Peach <martin AT loplop DOT com>
cc:	djgpp AT delorie DOT com
Subject:	Re: Use of recursion
In-Reply-To:	<830qak$s8k@tandem.CAM.ORG>
Message-ID:	<Pine.SUN.3.91.991213102748.29470F-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 12 Dec 1999, Martin Peach wrote:

> I think that recursion can be dangerous because of the possibility of stack
> overflow, which is a weak spot in most computer architectures, in that the
> cpu blindly allocates memory to the stack without first checking to see if
> it is available

This can be handled by using the stackavail library function.  It's
non-portable, though.

> An architecture that uses a separate memory space for the
> stack would be preferable, but that doesn't seem to be in the works

Actually, it's quite possible to make the stack be overflow-protected,
by defining a separate, expand-down segment for it.  This is actually
how DJGPP v1.x worked.  However, the downside was that
-fomit-frame-pointer didn't work, so v2.x stopped using that model.

Unfortunately, setting up stack overflow protection without losing
-fomit-frame-pointer is such a pain in the DPMI environment, that
nobody had enough motivation to make it happen.

- Raw text -