From owner-freebsd-hackers Tue Jul 20 3:11:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 83087152B3 for ; Tue, 20 Jul 1999 03:11:46 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id MAA07923; Tue, 20 Jul 1999 12:10:21 +0200 (CEST) (envelope-from des) To: "Kelly Yancey" Cc: "Dag-Erling Smorgrav" , Subject: Re: Overcommit and calloc() References: <002201bed217$e94beae0$291c453f@kbyanc.alcnet.com> From: Dag-Erling Smorgrav Date: 20 Jul 1999 12:10:20 +0200 In-Reply-To: "Kelly Yancey"'s message of "Mon, 19 Jul 1999 14:52:55 -0400" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Kelly Yancey" writes: > I don't know how many programs make use of calloc() but would not a more > efficient algorithm be to better integrate it with malloc() such that if > there is a fragment on the heap which can be used, bzero() it and return > that, otherwise, simply call sbrk() and return that (since it is already > zero'ed). Currently, in the event that malloc() simply returns newly > sbrk()'ed memory, we unnecessarily zero it again. I don't see the point. I've seen very few examples of justified calloc() use. For instance, I see a lot of people use calloc() instead of malloc() when allocating strings, just to make sure they'll be terminated after a strncpy(), instead of simply setting the last character to '\0' after the strncpy(). When I allocate memory, I usually intend to put something in it. There's always the odd struct sockaddr_in which I bzero() before filling it in, but they're usually on the stack. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message