Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: why is free() a void?
Message-ID: <14363@smoke.brl.mil>
Date: 7 Nov 90 08:36:58 GMT
References: <1749@meaddata.meaddata.com> <212@smds.UUCP>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <212@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
>The specs more or less explicitly provide that the users of malloc/free
>have all of the responsibility for using them without error.  The
>system is not obliged to do error checking.  It is at liberty to do
>something indeterminately awful if the programmer makes an error.
>All of this in one of the most primitive and least structured aspects
>of C.  Grumble, grumble, grumble.

If you really want thorough arena checking, you have to take a significant
performance hit.  Since it can be implemented outside the standard library,
that's a logical place for it.  People whose code doesn't have bugs would
be annoyed if all that unnecessary arena checking were forced upon them.

You can get a very nice (if I do say so myself) memory-allocation "wrapper"
that we call the "Mm package" free from the BRL MUVES project.  While Mm is
part of a larger system and may be tricky to configure outside the intended
compilation environment, it was designed to be useful in other projects and
has been used in them.  The additional overhead can be turned on to any
extent that you feel necessary.  It can even generate movie scripts for the
"anim" system.