[Libvir] [patch 1/5] iptables: fix invalid free
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. 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.
 - http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html
More information about the libvir-list