WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH V7 4/7] libxl, Introduce libxl__realloc.

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH V7 4/7] libxl, Introduce libxl__realloc.
From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Date: Thu, 21 Jul 2011 12:34:58 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 21 Jul 2011 04:35:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1311234568.32010.21.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1311197072-16003-1-git-send-email-anthony.perard@xxxxxxxxxx> <1311197072-16003-5-git-send-email-anthony.perard@xxxxxxxxxx> <1311234568.32010.21.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 21 Jul 2011, Ian Campbell wrote:

> On Wed, 2011-07-20 at 22:24 +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> > ---
> >  tools/libxl/libxl_internal.c |   20 ++++++++++++++++++++
> >  tools/libxl/libxl_internal.h |    1 +
> >  2 files changed, 21 insertions(+), 0 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> > index e259278..527ebc5 100644
> > --- a/tools/libxl/libxl_internal.c
> > +++ b/tools/libxl/libxl_internal.c
> > @@ -102,6 +102,26 @@ void *libxl__calloc(libxl__gc *gc, size_t nmemb, 
> > size_t size)
> >      return ptr;
> >  }
> >
> > +void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size)
> > +{
> > +    void *new_ptr = realloc(ptr, new_size);
>
> On failure realloc will return NULL but not free the old pointer, so I
> think in that case you will set alloc_ptrs[i] to NULL but not actually
> free the old pointer, hence leaking it.

Oops, I'll fix that, and just return new_ptr (without removing the pointer
from gc).

> I think you can just check for new_ptr == NULL and return NULL up front.
> Normally that would leak the old ptr but by leaving it in the gc array
> we avoid that pitfall.
>
> If new_size==0 then realloc behaves as free. I reckon you can just
> return NULL then too and allow the gc to clean up. Or you could outlaw
> such uses in this interface and abort(), that seems harsh however.

I think I will remove the pointer from gc, so libxl__realloc will behave
as expected and free stuff if asked.

> BTW libxl__free_all does cope correctly with NULLs mid-way through
> alloc_ptrs[] which did concern me initially.

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>