Path: utzoo!attcan!uunet!samsung!crackers!jjmhome!smds!rh
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: why is free() a void?
Summary: Storage allocators are dangerous to your software
Message-ID: <214@smds.UUCP>
Date: 27 Oct 90 04:24:14 GMT
References: <1749@meaddata.meaddata.com> <212@smds.UUCP> <1990Oct26.134649.2195@diku.dk>
Organization: SMDS Inc., Concord, MA
Lines: 63

I wrote:

   It is easier (and faster) to put the allocation control information
   in memory adjacent to the allocated block in allocators which use free
   lists (bit mapped buddy-system allocators are a different matter.)

   IMNSHO this is not nice.  It is a source of mystery bugs.  An array
   overwrite in allocated memory can wipe out control information; the
   consequence doesn't hit you until much later.

Niels J|rgen Kruse comments:

   If thre is no adjacent control information, the array overwrite
   will just scribble over some of the data you have in the next
   block.  This is not a source of mystery bugs?  Your program may
   not dump core, but the output will be slightly corrupted.  Ugh.

$my reply

Quite true -- array overwrites are bugs.  There are two philosophies
about how utilities should respond to incorrect input, i.e. bugs.
One approach says that the utility is not obliged to do anything
predictable in response to errors because you should never write
code with errors in it.

Much as I admire people who can actually write code that is error
free I must admit that I am not one of them -- I make mistakes from
time to time.  As a result I prefer a more robust approach which says
that utilities should help you as much as is feasible when you make
mistakes.

The allocator/deallocator which I use goes a fair ways towards doing
this.  Features include:

1)	Control information is separated from allocated storage.
2)	Each allocation records the origin of the allocation request.
3)	All return addresses are checked to make sure that they are
	valid.
4)	Each allocated block is padded with four check bytes.   The
	deallocator tests whether the check bytes have been touched.
5)	Control information block stores the time of origin (or
	equivalent) for each allocation (highly useful for finding
	storage leaks.)
6)	The allocator package prints a map of allocated memory when
	an error is detected.  The map includes address, size, origin,
	date, and control block ID for each block, and a description
	of the trapped error.  I find this information somewhat more
	useful than a core dump.

There is a price to be paid for this -- it requires more storage (but
not time) than a bare bones allocator.  Some, perhaps most, will view
this as an unacceptable price.  For my own part, I prefer to pay the
price because memory allocation bugs can be, in my experience, among the
more difficult (expensive in time and effort) bugs to track down.

Incidentally, I don't doubt that there are better allocation packages
than the one I use.  However I have been using it for years and I find
that it eliminates an entire class of problems.  
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.