From owner-cvs-include Tue Nov 15 09:06:21 1994 Return-Path: cvs-include-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.8/8.6.6) id JAA09265 for cvs-include-outgoing; Tue, 15 Nov 1994 09:06:21 -0800 Received: from bsd.coe.montana.edu (bsd.coe.montana.edu [153.90.192.29]) by freefall.cdrom.com (8.6.8/8.6.6) with ESMTP id JAA09259; Tue, 15 Nov 1994 09:06:14 -0800 Received: (nate@localhost) by bsd.coe.montana.edu (8.6.8/8.3) id KAA09414; Tue, 15 Nov 1994 10:10:15 -0700 Date: Tue, 15 Nov 1994 10:10:15 -0700 From: Nate Williams Message-Id: <199411151710.KAA09414@bsd.coe.montana.edu> In-Reply-To: Paul Traina "Re: cvs commit: src/include malloc.h Makefile" (Nov 15, 9:01am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Paul Traina Subject: Re: cvs commit: src/include malloc.h Makefile Cc: CVS-commiters@freefall.cdrom.com, cvs-include@freefall.cdrom.com Sender: cvs-include-owner@FreeBSD.org Precedence: bulk > Why would we want the system5 fatmalloc? Why do we want malloc() at all? Umm, do you have *any* idea what you are talking about? The libmalloc() supplied in 1.1.5 is Mark Moraes replacement malloc() that is *much* more frugal on memory use with only a slight performance hit. It was my intent to replace the version in 2.X with this version, but due to lack of time and testing on my part I didn't get time to do it. By adding it to 2.X we have it in public where it *may* get more testing than by sitting doing nothing. It is leaner/meaner than the stock version and not fat in the least bit. The second question seems rather silly to me. Gee, I don't know why we want malloc(), maybe since the ability to do dynamic memory in programs is generally considered a good feature? Nate