Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hp-pcd!hpcvca!charles
From: charles@hpcvca.CV.HP.COM (Charles Brown)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Memory Protection!
Message-ID: <1410052@hpcvca.CV.HP.COM>
Date: 31 Aug 90 01:21:02 GMT
References: <1145.26bd4989@waikato.ac.nz>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 35

>>      So could a Unix guru please enlighten me?  Is it actually
>> considered evil to free memory yourself, or is it one of those
>> conventions that just grew?

> Its not evil but I think its more a matter of laziness.  Keeping
> track of what memory was allocated can become tricky particularly if
> you have an unrecoverable error (in which case you normally just
> print a message and exit()).  Saying it is more efficient is merely a
> justification for sloppy coding.
> -- 
> Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney)

I think this notes string has turned religeous.  Since I was the one
who spoke of the desirability of not freeing memory, I will attempt to
put my comments into some perspective.

Certainly it is not evil.  If I could have seen any benefit to doing
so in the application I wrote I would have done so.  But like so many
things in life, it depends upon the circumstance.  In my program there
was no possibility of freeing or reusing memory until the program was
ready to exit.  In that case it would be stupid (rather than lazy) to
put in the extra code since it would make the program bigger and cause
it to run (slightly) slower.  This is not the same as error checking.
I never skimp on checking; I just don't trust the user or the system
enough for that.  And I expect my software to recover gracefully from
my errors.

If I encapsulate the symbol table (which is what was malloc'ing memory
in the above program) into another application which may want to free
memory then it will certainly be desirable to provide the code to free
that memory.  At that time I will.  Until then it would be a waste of
time and space.
--
	Charles Brown	charles@cv.hp.com or charles%hpcvca@hplabs.hp.com
			or hplabs!hpcvca!charles or "Hey you!"