Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Free() in return from main

0 views
Skip to first unread message

rookie_rookie

unread,
Jul 4, 2008, 2:46:30 AM7/4/08
to
Should we always free memory allocated through malloc() in a process
even just before return from main(in non-server application).If the
OS does it automatically, is free() an avoidable overhead?
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Richard Bos

unread,
Jul 8, 2008, 3:29:26 PM7/8/08
to
rookie_rookie <gauravd...@gmail.com> wrote:

> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).If the
> OS does it automatically, is free() an avoidable overhead?

You should get in the habit of always doing The Right Thing, even when
you believe that right at that moment, you would not need to do The
Right Thing. If you teach yourself to rely on shortcuts, you will sooner
or later cut a short somewhere it shouldn't be cut.

Richard

Barry Schwarz

unread,
Jul 8, 2008, 3:29:58 PM7/8/08
to
On Fri, 4 Jul 2008 01:46:30 -0500 (CDT), rookie_rookie
<gauravd...@gmail.com> wrote:

>Should we always free memory allocated through malloc() in a process
>even just before return from main(in non-server application).If the
>OS does it automatically, is free() an avoidable overhead?

Do you think if the OS does it that there is no overhead. Someone
always pays; there is no free lunch. You reserved the resource. It
seems only fair you should release it. You should also fclose any
file you fopen.


Remove del for email

Hans-Bernhard Bröker

unread,
Jul 8, 2008, 10:18:34 PM7/8/08
to
rookie_rookie wrote:
> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).If the
> OS does it automatically, is free() an avoidable overhead?

That's a question for your OS to answer. C doesn't care what happens
after your program has exited. If you want your code to be independent
of the target platform, you should of course free() all you can, just in
case.

Thomas Richter

unread,
Jul 8, 2008, 10:18:31 PM7/8/08
to
rookie_rookie schrieb:

> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).

It's at least good style, and I've seen operating systems that did not
clean up behind you.

> If the
> OS does it automatically, is free() an avoidable overhead?

IMHO, no. But this is rather an opinion than a fact. I would do it
for matters of good style. Consider that you change the program later
on such that the single allocation that is now released by the operating
system is then run multiple times, and you leak memory on each iteration -
this might become a problem.

Besides - I wouldn't use malloc() in C++ - that's the first point.

So long,
Thomas

Jack Klein

unread,
Jul 8, 2008, 10:18:37 PM7/8/08
to
On Fri, 4 Jul 2008 01:46:30 -0500 (CDT), rookie_rookie
<gauravd...@gmail.com> wrote in comp.lang.c.moderated:

> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).If the
> OS does it automatically, is free() an avoidable overhead?

The answer to your first question (I assume it is a question despite
the lack of a '?'), is yes, you should.

Your second incorrectly punctuated question is subjunctive, based on
whether or not "the OS" does it automatically.

Do you think that "the OS" you are using is actually "THE OS", that is
the only one? There are some operating systems that claim to release
all memory allocated by a program when it exits. There are at least
some circumstances where at least some of these operating systems do
not always perform that task correctly.

What do you care about overhead when an application is exiting?

Professional quality programming demands proper initialization and
proper clean up.

Not to mention what happens when somebody else wants to take the
original program and use it as a subroutine in a bigger program some
day.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jasen Betts

unread,
Jul 10, 2008, 2:02:33 PM7/10/08
to
On 2008-07-04, rookie_rookie <gauravd...@gmail.com> wrote:
> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).If the
> OS does it automatically, is free() an avoidable overhead?

yes. but for complex programs freeing is good as then special tools
can be used to detect lost unfreed memory - which can cause
long-running processes to misbehave as it builds up...

Bye.
Jasen

Paul D. DeRocco

unread,
Aug 7, 2008, 4:02:12 PM8/7/08
to
> "rookie_rookie" <gauravd...@gmail.com> wrote

>
> Should we always free memory allocated through malloc() in a process
> even just before return from main(in non-server application).If the
> OS does it automatically, is free() an avoidable overhead?

If a program does some deallocation, then you should probably be consistent
and try to balance every allocation with a deallocation. But there are many
applications in which all you ever do is allocate, and abort if you ever run
out of memory. In this case, it's hardly worth going to the trouble.

For instance, I just finished writing a command line directory lister (a
fancier version of "ls") that allocates a chunk of memory to hold each file
name and its attributes. Once the list of files is built and sorted, it is
written out, and the program terminates. In that case, there is no point in
going through the list and freeing everything. When the program exits, the
few large pieces of memory that the C library requested from the OS are
freed by the OS much more quickly than the C library could deallocate the
potentially huge number of tiny pieces that the program allocated
internally.

--

Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com

0 new messages