Date: 20 Jul 1999 12:10:20 +0200 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: "Kelly Yancey" <kbyanc@alcnet.com> Cc: "Dag-Erling Smorgrav" <des@flood.ping.uio.no>, <freebsd-hackers@freebsd.org> Subject: Re: Overcommit and calloc() Message-ID: <xzppv1nbpir.fsf@flood.ping.uio.no> In-Reply-To: "Kelly Yancey"'s message of "Mon, 19 Jul 1999 14:52:55 -0400" References: <002201bed217$e94beae0$291c453f@kbyanc.alcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Kelly Yancey" <kbyanc@alcnet.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzppv1nbpir.fsf>