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