Hi Roger! :-)

 RS> To me there is no exception.  I would write the cleanup code.  If 
 RS> you compiled you code using a memory diagnostic library I am sure it 
 RS> would flag the lack of matching calls to free.
Sure. I make a distinction between code I write just for my amusement and
code that I intend to release for others to use. In my own personal stuff,
I only do cleanup stuff when it is either needed (because the allocated
memory is not needed any more, but the program continues to run) or an
interesting programming exercise in itself. These are programs I do just
for fun, so I stop where the fun stops. ;) If I release the code, I do all
the cleanup stuff.

 RS> Obviously we have differing opinions here.  I don't think that the 
 RS> startup code, or the OS, or the libraries do cleanup as a service to 
 RS> the programmer to make things easier on him.
Agreed. It comes at almost zero cost in the OS... it needs to be able to
free a process' memory anyway for handling segmentation faults and the
like, and it usually is a very simple operation for the OS (malloc and free
live in the C library, the OS usually only keeps track of the total amount
of memory a process uses). So, the intent was not making the lives of
applications programmers easier, but humans being what they are, some use
it to make their lives easier. ;)

 RS> If that is the way you choose to write code, that's on you.  I just 
 RS> don't like to do it that way.  In a way it's a philosophical thing.  
 RS> My philosophy is this; never make assumptions, and leave things the 
 RS> way you found them.
No argument on the second point, but there are some assumptions about the
runtime environment that one has to make. No program can run without some
kind of context.

In a way, having to allocate and free dynamic memory by hand is an
indication of how primitive a language C really is. It has advantages and
disadvantages. You gain control, but also more opportunities to introduce
bugs. ;)

Ciao
Pascal

--- Msged/LNX 6.1.1