Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!kremer
From: kremer@cs.odu.edu (Lloyd Kremer)
Newsgroups: comp.lang.c
Subject: Re: What if I don't free() all my dynamically allocated memory?
Summary: The PC side of things
Keywords: On a Unix system, that is.
Message-ID: <8395@xanth.cs.odu.edu>
Date: 9 Apr 89 22:58:01 GMT
References: <2580@ssc-vax.UUCP>
Organization: Old Dominion University, Norfolk, Va.
Lines: 92



In article <2580@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes:
>Anyway, I'm wondering if it's ok for me to just leave the freeing
>out altogether.  Unix will free all of my resources for me anyway
>right?  Is there any problem with doing this?
>
>Of course, I realize this would cause serious problems if ever
>ported to a lowly PC, but I don't care ;-)

In article <2367@maccs.McMaster.CA> cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) writes:
>   Actually, this may be ok on a PC, too.  I don't know how the typical
>C compiler on a PC handles memory allocation, but I would suspect it's
>similar to Turbo Pascal:
>
>   Anyway, just thought you might like to know the "lowly" PC might even
>be able to handle your code.


I can't speak for Turbo Pascal, but I am familiar with memory allocation
in MSC 5.1, and there is at least one danger area for programmers.

An applications program (like a C program) resides in a "memory block"
obtained from the operating system when the program is invoked (usually by
the shell, COMMAND.COM).  (Actually, the program is initially given all
available memory, and the compiler run-time start-up code then modifies the
size of its memory block to return to the operating system that which it
does not anticipate needing.)  The operating system recognizes this memory
block as belonging to your program, as opposed to the interrupt vector table,
system areas, device drivers, bit-mapped screen image, etc.

The compiler considers your memory block as divided into various areas such
as code space, initialized data, uninitialized data, etc.  One of these areas
is what can be thought of as "mallocable memory."  But this mallocable memory
is still part of your program as far as the operating system is concerned.

There are several functions available for obtaining memory at run-time:

	malloc()
	calloc()
	realloc()
	_nmalloc()	/* malloc maps to this in small-data models */
	_fmalloc()	/* malloc maps to this in large-data models */
	halloc()

Of these, all but halloc() obtain memory from the mallocable memory area,
which lies within your memory block.  The operating system is petitioned
for additional memory only in the event that the mallocable memory becomes
exhausted.  Library code within your program then increases the size of your
program's memory block by an amount determined by 'extern unsigned _amblksiz'.
All allocation and freeing occur within your operating system memory block,
and when your program exits, the standard exit sequence returns your entire
memory block to the operating system, and all is well.

halloc() (allocate a huge block) is the great exception to this scheme of
things.  halloc() gets a new memory block *directly* from the operating
system, using the same system call as the shell used originally to get the
memory block for your program!  When you use halloc(), you are not under
anyone's auspices except the operating system (no one's looking out for you).
If you halloc() a lot of memory and fail to hfree() it, at program exit you
may very well be presented with the disheartening message:

Memory allocation error
Cannot load COMMAND, system halted

They should have added, "Have a nice day."  I have had the pleasure of
all-night debugging sessions tracing this type of error, and have come away
with the firm belief that the use of halloc() should be licensed.  Not that
halloc shouldn't exist; on a system as small as a PC, you sometimes need
"all the memory" to get any useful work done.  If it weren't there I'd no
doubt write my own in assembly.  But to use it is to play god with the
system memory maps, and you'd better be up to it!  Functions like atexit(),
onexit(), and signal() can help to ensure that everything is hfree'd, but
it's ultimately up to the programmer to have a flawless conception of the
flow control of his program in all cases. (Yeah, right.)

To sum up: is it OK not to free memory on a PC?  Yes, as long as you don't
use halloc(), otherwise watch out!

As I recall, the original questioner was asking about UNIX(tm) systems.
Oh, there's no problem on UNIX...UNIX is smart!  :-)
Unless the "sticky bit" of a program is set, UNIX frees all memory directly
or indirectly associated with a program on program exit.
MSDOSN'T.

#ifdef OPINION
The more I learn about other operating systems, the more I like UNIX(tm) :-)
#endif

					Lloyd Kremer
					Brooks Financial Systems
					{uunet,sun,...}!xanth!brooks!lloyd