🚀 go-pugleaf

In article <36Flx*mhd@yaps.rhein.de> arno@yaps.rhein.de writes:

>In article <1995Sep19.061336.21215@sq.com>, Mark Brader writes:
>
>> > Does the C standard guarantee that storage allocated by malloc() is
>> > freed during program termination?
>> 
>> The question is meaningless.  The standard specifies what happens, or
>> may happen, *during* execution of a program, not afterwards.
>
>But it *does* specify that during termination flies are closed,
>doesn't it? Wouldn't that contradict your statement?

I don't think so.  

If you fclose a file stream, you would expect that another program 
somewhere can now access it immediately.  On the other hand, all free 
says is that the program has stopped using a certain block of memory, 
not that it should be made available to other programs to use.  It 
could quite reasonably be held available for the program in case it 
wished to use again.  (And only the OS could reasonably make that 
decision) It would not, however, be reasonable to hold a file reserved 
in the same way. (IMHO)

A C program has the ability to directly manipulate files, including 
the ability to force a file closed. So requiring it to close the files 
at termination is something that it could easily have done anyway.  It 
does not have the ability to determine how the machines pool of memory 
is geven to, or taken from, a process.  So you can't specify in a 
program standard what only the OS can be responsible for.

Of course, these arguments are akin to reading the footnotes. :-)
However sensible, they have no 'legal' force.  None-the-less, I 
think the difference in the way files and memory are used by a program 
is sufficient to make it reasonable to put a requirement on the 
program to close files, but leave the release of memory to the OS.


-- 
============================================================================
 Ian Cargill  CEng MIEE  | Find out about the Association of C and C++ Users
 Soliton Software Ltd.   | info@accu.org OR  http://bach.cis.temple.edu/accu