Path: utzoo!mnetor!uunet!husc6!cmcl2!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: <7785@brl-smoke.ARPA>
Date: 28 Apr 88 19:22:06 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <7750@brl-smoke.ARPA> <474@bnlux0.bnl.gov>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11

In article <474@bnlux0.bnl.gov> drs@bnlux0.UUCP (David R. Stampf) writes:
>(in one example I didn't need the full generality that malloc
>gave me, since I was always allocating fixed length blocks, so I wrote my own
>that took advantage of the machine that I was running on (Mac) ...

The correct way to do this is to write your own MyAlloc() function
that calls on the library malloc() to obtain big chunks of heap which
it then subdivides.  You have no way of knowing what one of the C
library routines may need to malloc(), so it is a mistake to replace
malloc() with one that does not have the full semantics.  On unusual
architectures it is a mistake to replace it, period.