Path: utzoo!attcan!uunet!samsung!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!janus.usq.edu.au!zeus!s64421
From: s64421@zeus.usq.edu.au (house ron)
Newsgroups: comp.lang.c
Subject: Re: why is free() a void?
Message-ID: <1990Oct29.121356.20818@zeus.usq.edu.au>
Date: 29 Oct 90 12:13:56 GMT
References: <1749@meaddata.meaddata.com> <212@smds.UUCP> <1990Oct26.134649.2195@diku.dk> <214@smds.UUCP>
Organization: Univ. College of Sth. Queensland
Lines: 32

rh@smds.UUCP (Richard Harter) writes:

>Niels J|rgen Kruse comments:

>>   If thre is no adjacent control information, the array overwrite
>>   will just scribble over some of the data you have in the next
>>   block.  This is not a source of mystery bugs?  Your program may
>>   not dump core, but the output will be slightly corrupted.  Ugh.

>Quite true -- array overwrites are bugs.  There are two philosophies
>about how utilities should respond to incorrect input, i.e. bugs.
>One approach says that the utility is not obliged to do anything
>predictable in response to errors because you should never write
>code with errors in it.

>Much as I admire people who can actually write code that is error
>free I must admit that I am not one of them -- I make mistakes from
>time to time.  As a result I prefer a more robust approach which says
>that utilities should help you as much as is feasible when you make
>mistakes.

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!
-- 
Regards,

Ron House.   (s64421@zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)