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: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH V7 4/7] libxl, Introduce libxl__realloc.
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Thu, 21 Jul 2011 08:49:28 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 21 Jul 2011 00:50:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1311197072-16003-5-git-send-email-anthony.perard@xxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <1311197072-16003-1-git-send-email-anthony.perard@xxxxxxxxxx> <1311197072-16003-5-git-send-email-anthony.perard@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.

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.

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

Ian.

> +    int i = 0;
> +
> +    if (ptr == NULL) {
> +        libxl__ptr_add(gc, new_ptr);
> +    } else if (new_ptr != ptr) {
> +        for (i = 0; i < gc->alloc_maxsize; i++) {
> +            if (gc->alloc_ptrs[i] == ptr) {
> +                gc->alloc_ptrs[i] = new_ptr;
> +                break;
> +            }
> +        }
> +    }


> +
> +
> +    return new_ptr;
> +}
> +
>  char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...)
>  {
>      char *s;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4580be9..64942e6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -145,6 +145,7 @@ _hidden int libxl__ptr_add(libxl__gc *gc, void *ptr);
>  _hidden void libxl__free_all(libxl__gc *gc);
>  _hidden void *libxl__zalloc(libxl__gc *gc, int bytes);
>  _hidden void *libxl__calloc(libxl__gc *gc, size_t nmemb, size_t size);
> +_hidden void *libxl__realloc(libxl__gc *gc, void *ptr, size_t new_size);
>  _hidden char *libxl__sprintf(libxl__gc *gc, const char *fmt, ...) 
> PRINTF_ATTRIBUTE(2, 3);
>  _hidden char *libxl__strdup(libxl__gc *gc, const char *c);
>  _hidden char *libxl__dirname(libxl__gc *gc, const char *s);



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