Date: Fri, 27 Jul 2001 10:15:29 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Kris Kennaway <kris@obsecurity.org> Cc: arch@FreeBSD.org Subject: Re: Nuking all malloc wrappers (Re: cvs commit: src/usr.bin/nm nm.c) Message-ID: <20010727101529.B43542@dragon.nuxi.com> In-Reply-To: <20010724130418.A34051@xor.obsecurity.org>; from kris@obsecurity.org on Tue, Jul 24, 2001 at 01:04:18PM -0700 References: <200107241408.f6OE83j65583@freefall.freebsd.org> <20010724130418.A34051@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 24, 2001 at 01:04:18PM -0700, Kris Kennaway wrote:
> I don't understand why you're doing this. Increasing code duplication
> by expanding out a local function seems like a pessimization to me.
Check the diffs.
Two programs wrote "emalloc" as:
void *
emalloc(size_t s)
{
void * p;
if ((p = malloc(s)) == NULL)
errx(1, NULL);
bzero(p, s); (or memset(p, 0, s))
return p;
}
ie, they rolled their own calloc(). That is a pestimazation as your libc
may easily have a platform-specific optimized one. And the name emalloc
implies malloc, not calloc semantics. So it is misleading to the reader.
Which leads to the issue of someone not knowing emalloc is used in a
particular program (or estrdup), so they use straight malloc or strdup --
breaking coherence w/in the program. (yes I found cases of this)
Another case of "optimized" wrapper was the realloc one that didn't trust
that our libc was ANSI compliant, so it tested `p' for NULL and called
malloc if it was, else it went ahead and called realloc. Since ANSI says
that is exactly how realloc must function, effectively we were testing
for a NULL `p' twice. Again in this case, my change wasn't a
pessimization. But rather it lead to easier to read and audit code.
Also, in all but the xlint case, I there were only a hand full of
"emalloc" uses. So they were only saving a hand full of testing malloc's
return value, while adding the code overhead of another function call.
--
-- David (obrien@FreeBSD.org)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010727101529.B43542>