Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site kovacs.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!hplabs!sdcrdcf!randvax!kovacs!day
From: day@kovacs.UUCP (Dave Yost)
Newsgroups: net.works,net.lang.c
Subject: Re: 4.2 malloc() on Suns?
Message-ID: <257@kovacs.UUCP>
Date: Sat, 14-Sep-85 21:04:46 EDT
Article-I.D.: kovacs.257
Posted: Sat Sep 14 21:04:46 1985
Date-Received: Thu, 19-Sep-85 07:26:14 EDT
References: <1285@brl-tgr.ARPA> <1506@umcp-cs.UUCP> <5079@allegra.UUCP> <514@im4u.UUCP>
Reply-To: day@kovacs.UUCP (Dave Yost)
Organization: Robt Abel & Assoc, Hollywood
Lines: 22
Xref: watmath net.works:1137 net.lang.c:6461
Summary: I have a souped-up version of 4.2 malloc

Keywords:

In article <514@im4u.UUCP> riddle@im4u.UUCP (Prentiss Riddle) writes:
>In article <5079@allegra.UUCP> jpl@allegra.UUCP (John P. Linderman) writes:
>>
>> 		 ...Another ``gotcha''  [in 4.2bsd malloc()]
>>to beware of is that space, once allocated, is never broken
>>into smaller pieces.  For example, if I allocate a 4 meg
>>temporary workspace, free it, then allocate a 2 meg area,
>>malloc will not reuse the freed space, it will try for a new
>>area, and, thanks to the aforementioned quirks, it will fail
>>with the standard 6 meg per-process limit.  Dunno if this is
>>fixed under 4.3.
>
>Does anyone know if this has been fixed in the Sun version of malloc()?

I have a souped-up version of malloc derived from the 4.2 malloc
that reuses all available freed space before asking the system for
more.  Plus it does other neat things.  I was thinking of posting
it to net.sources sometime soon.

--dave yost


Brought to you by Super Global Mega Corp .com