Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!mcnc!ecsvax!dukeac!bet
From: bet@dukeac.UUCP (Bennett Todd)
Newsgroups: comp.lang.c
Subject: Re: What if I don't free() all my dynamically allocated memory?
Keywords: Not on a Unix system, that is.
Message-ID: <1391@dukeac.UUCP>
Date: 5 May 89 18:10:51 GMT
References: <2580@ssc-vax.UUCP> <386@nbires.nbi.com> <1384@dukeac.UUCP> <2239@athertn.Atherton.COM>
Reply-To: bet@dukeac.UUCP (Bennett Todd)
Organization: Radiology, Duke Med. Center, Durham, NC
Lines: 23

In article <2239@athertn.Atherton.COM> paul@athertn.Atherton.COM (Paul Sander) writes:
>I once programmed in an environment that did NOT, repeat NOT, automatically
>free allocated heap memory when a program terminated.
> [...]
>Deciding goodness or badness is left as an exercise for the reader; my point
>is that this environment exists, and if you want your code to port to it,
>free() your stuff.

I certainly would *not* want any code of mine ported to an environment like
that! I decided a good bit ago that I wasn't going to worry about 6 character
monocase unique names, no lines less that 80 characters long, no text strings
longer than 80 characters long, never using bitfields, no subroutines longer
than a couple of hundred lines, no arrays larger than 64K, no using '_' in
external identifiers, or any other of the myriad deficiencies that show up
occasionally in obscure environments. Instead, I'd try to write code to be as
simple and clear as I could manage (which often means avoiding convoluted
names, long lines, multiline text strings, bitfields, etc. -- but for reasons
of clarity, not portability to defective environments). I am interested in
porting to what is nice to use now, and what will be better in the future. I
am not interested in porting to what I am glad we've outgrown.

-Bennett
bet@orion.mc.duke.edu