why is free() a void?

Richard Harter rh at smds.UUCP
Tue Oct 30 19:40:43 AEST 1990


In article <1990Oct29.121356.20818 at zeus.usq.edu.au>, s64421 at zeus.usq.edu.au (house ron) writes:

re my comments on memory allocators

> Actually, the way a utility can help _me_ when I overwrite memory is
> by causing the most drastic crash possible a.s.a.p.!  Trying to
> minimise the effects of an error is useful if the error gets past
> the checking stage, but it makes it _much_ more likely that errors
> _do_ escape notice.  A good ol' segmentation fault tends to alert you
> to problems!

Well, I agree, sort of.  The point is that off-the-shelf malloc/free
is not guaranteed to do anything of the sort if you do a memory overwrite.
The behaviour is undefined; you may crash now or you may crash later.
What is worse is that two calls to free for the same block (in a linked
list implementation) are very likely to postpone the problem to a later
time.  The purpose of checking is to make sure that a.s.ap is in fact
a.s.a.p instead of some indeterminate random time in the future.
-- 
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.



More information about the Comp.lang.c mailing list