Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcnc!duke!bet
From: bet@bent (Bennett Todd)
Newsgroups: comp.unix.wizards
Subject: Re: Need debugging version of malloc()/free()
Message-ID: <14721@duke.cs.duke.edu>
Date: 10 Jun 89 23:11:06 GMT
References: <850@pcsbst.UUCP>
Sender: news@duke.cs.duke.edu
Reply-To: bet@bent (Bennett Todd)
Organization: Diagnostic Physics, Raddiology, DUMC
Lines: 22
In-reply-to: jkh@pcsbst.UUCP (jkh)

My error-checking wrappers library (libbent) does this in its wrappers
around malloc/free/realloc (emalloc, efree, and erealloc, respectively).
I sometimes regret having done this, since as a result of this decision,
the pointers handled by emalloc/efree/erealloc aren't interchangeable
with malloc/free/realloc, whereas the other cookies that are passed
about (file descriptors, FILE pointers, and so forth) are
interchangeable between my e* wrappers and the lower level functions. On
the other hand, I haven't gotten into trouble as a result of mixing yet,
and the additional checking has helped me catch some evil bugs quickly.
My code has emalloc over-allocate by twice the length of a header
structure, which includes a magic number and the allocation length. One
copy is prepended, and one appended, and the pointer to the middle space
is returned. On efree and erealloc the headers and trailers are checked;
on efree they are mangled in a predictable fasion, so that double
freeing can be detected. This catches double freeing, freeing bogus
pointers, and running off either end of the array. I use these in all my
production code. Although they don't catch problems as quickly as some
other more ambitious packages out there, they also don't inflict enough
overhead to make me want to leave them out of production code.

-Bennett
bet@orion.mc.duke.edu