[Libvir] [patch 1/5] iptables: fix invalid free

Mark McLoughlin markmc at redhat.com
Thu Mar 22 11:40:17 UTC 2007


On Thu, 2007-03-22 at 12:22 +0100, Jim Meyering wrote:
> David Edmondson <dme at sun.com> wrote:
> 
> > On Wed, Mar 21, 2007 at 04:38:00PM +0100, Jim Meyering wrote:
> >> I interpret "wrappers", above, to mean more than just a calloc-like wrapper.
> >>
> >> A malloc (not calloc, of course) wrapper that always initializes can
> >> mask what would have otherwise been a used-uninitialised error, and what
> >> would still be a logical U.I. error.
> >
> > That seems silly.  If the wrapper is defined as zero-initalising then
> > it cannot be an error to assume that it zero-initalises.
> 
> What seems silly?  A malloc() wrapper that initializes the
> memory it allocates?  That's the case in which errors can be masked.
> A function intended to be used as a malloc or realloc replacement should
> not initialize its memory -- at least not by default.  A calloc-wrapper
> _must_ do that.  Not the others.

	Wow, this is a weird little side-track :-)

	I think the confusion is just around what the term "malloc() wrapper"
means. I mean it purely as "a memory allocation function", you seem to
interpret it as "a function which overrides the malloc() symbol and has
the same semantics as malloc()".

	e.g. I would define g_malloc(), g_malloc0(), g_new() and g_new0()
etc.[1] as malloc() wrappers ... but you wouldn't? They have different
semantics from malloc() and some of them have the semantic "zero
initialise the newly allocated memory".

	So, sure, a zero-initialising replacement for the malloc(3) symbol
would be stupid.

Cheers,
Mark.

[1] - http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html




More information about the libvir-list mailing list