Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: inkey$, noecho, and other impossibles
Message-ID: <9338@smoke.BRL.MIL>
Date: 11 Jan 89 08:56:51 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp> <84629@sun.uucp> <15396@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 13

In article <15396@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>Possibly.  In fact, malloc() might be one (`too machine dependent').

malloc() can be implemented on all known systems for which a C
implementation is otherwise feasible.  It might not be able to
grow the process allocation at run time, but it can certainly
dole out parcels from a pool that was allocated at link time.

The stack is also like this on a lot of systems; it needs to be
specified large enough at link time.  The main operational
difference is that malloc() reports failure when it runs out of
memory to give away, whereas running out of stack usually has
more catastrophic results.