why is free() a void?

Richard Minner rtm at christmas.UUCP
Mon Oct 29 09:38:15 AEST 1990


In article <1990Oct25.152057.23024 at zoo.toronto.edu> henry at zoo.toronto.edu (Henry Spencer) writes:
>In article <1749 at meaddata.meaddata.com> rob at pmserv.meaddata.com writes:
>>How do we know there was a problem??  ...
>
>"Bus error - core dumped."  Handing free() an improper pointer is a major
>error, and one that free() is *not* required to catch.  It can screw up in
>any manner it pleases if you do this.  There is little point in allowing
>for a return code just to complain about something you are *never* *ever*
>supposed to do in the first place.

Yes yes yes.  It seems to be a common misconception that the standard
library ought to do everything *you* want it to do, whatever that happens
to be.  The standard library is there to provide a foundation upon which
you can build whatever it is you need.  As such, it should do as little
as possible, yet still provide a means of accomplishing a great variety
of tasks.  That's what makes C so wonderfully small and general purpose
(even ANSI C :-).  It is extremely difficult to design a language to
do more for you without adding more restrictions (or at least more
complications).  (Of course, C++ is perfect in every way...-)

void free() is a good example.  It is not a function in isolation, it
is part of a very simple and basic memory allocation package.  There
are countless ways to manage memory, and it would be silly to try to
provide a comprehensive set with the language.  It is very smart to
provide a simple scheme.   That way, if your task is small or simple,
the standard library may be all you need.  If your task is large
or complex, you can add your own layer, with whatever error detection,
etc. you want.  I think most large projects would be well advised to
design a layer on top of the standard library.  Unfortunately, this
is often an upfront investment whose return is hard to `prove'.

-- 
Richard Minner  || {uunet,sun,well}!island!rtm     (916) 736-1323 ||
                || Island Graphics Corporation     Sacramento, CA ||



More information about the Comp.lang.c mailing list