What if I don't free() all my dynamically allocated memory?

Bennett Todd bet at dukeac.UUCP
Sat May 6 04:10:51 AEST 1989


In article <2239 at athertn.Atherton.COM> paul at 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 at orion.mc.duke.edu



More information about the Comp.lang.c mailing list