This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Liberty, asprintf(), malloc()


Just to clarify things about asprintf() and vasprintf().

These are part of the GNU libiberty (-liberty).  This library is sanctioned and blessed
by the Gods of Free Software, it is highly portable and few GNU software doesn't rely on
it.  We can use liberty calls at will.

W.r.t. malloc() uses here a few rules:

1) free where you call malloc whenever possible

2) functions can return malloc'ed things, but they cannot malloc things that are not
   explicitly returned to the caller (there are exceptions, see 3).
   In this case it is like the caller called malloc: it should free what was returned.

3) gdb provides a mechanism so things can be safely malloc'ed during a command execution.
   You don't have to free() where you malloc() but you must (absolutely must) create a
   "cleanup" for it.  You can them rest assured that it will be destroyed at the
   appropriate time (it borrows the ideas for OOP destructos).

These practices have been working fine for ages.  The memory leaks happen when people
fail to follow the coding conventions above.

One of the reasons we have this post-and-approval (or just post for the maintainers) is
that people who find some time and/or curiosity to look at the patches can find that
some rule has been broken, something condition was not handled, typos etc.
Everyone makes mistake, sometimes we do thins pressed by time etc. so it is good that
we have other people to help us catch things before they manifest themselves as bugs.

P.S.: Anyway, memory leaks are a risk of programming in C (or other languages that
require explicitly deallocation, deletions etc.)  Java does not have this problem,
but them it has the garbage collector...


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]