Path: utzoo!attcan!uunet!fernwood!apple!uokmax!munnari.oz.au!samsung!crackers!transfer!lectroid!jjmhome!smds!rh
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: why is free() a void?
Summary: Die yuppie scum program
Message-ID: <219@smds.UUCP>
Date: 30 Oct 90 08:40:43 GMT
References: <1749@meaddata.meaddata.com> <212@smds.UUCP> <1990Oct29.121356.20818@zeus.usq.edu.au>
Organization: SMDS Inc., Concord, MA
Lines: 23

In article <1990Oct29.121356.20818@zeus.usq.edu.au>, s64421@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.