Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del
From: del@thrush.mlb.semi.harris.com (Don Lewis)
Newsgroups: comp.lang.c
Subject: Re: Question about malloc() and free()
Message-ID: <1990Aug31.005355.17898@mlb.semi.harris.com>
Date: 31 Aug 90 00:53:55 GMT
References: <1990Aug27.184058.1936@everexn.uucp> <714.26dd34df@iccgcc.decnet.ab.com> <2223@idunno.Princeton.EDU>
Sender: news@mlb.semi.harris.com
Organization: Harris Semiconductor, Melbourne FL
Lines: 36

In article <2223@idunno.Princeton.EDU> rssutor@broccoli.Princeton.EDU (Robert S. Sutor) writes:
>
>Another good argument to free what you have malloc'ed, as has been stated
>before (here?), is that someone might decode to use your program or functions
>as subroutines of another program.  In that case it is definitely not a good
>idea to leave dead data tying up memory.

#define asbestos_suit_on

I'm going to argue against doing this blindly.  There is one particular
application that I have used and which will remain nameless.  This
application reads a bunch of data files on startup and builds a large
data structure in memory.  The data structure is significantly larger
than than available physical memory, but since this program is running
on a machine with virtual memory (sound of page faults happening...),
here is no problem, right?  After it has finished reading the data, the
program walks around the data structure (sound of more page faults)
and writes its output (except the last stdio buffer full) to a file.
Then the program goes into serious page fault mode for about 45
minutes.  I don't know what it does during this time, but I'd be willing
to bet that it is walking the data structure, freeing all the bits and
pieces of memory it has malloc'ed along the way.  Finally it calls
exit() which fflush's the rest of the output data.

It sure would be considerate if this program just called exit()
instead of wasting my time and a lot of cpu cycles doing something
totally useless.  I'd even be happy with a strategically placed
fflush() so that I could send the process a well deserved "kill -9".

#define asbestos_suit_off

Now that feels much better.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901