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

Re: [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__creat

Stefano Stabellini writes ("Re: [Xen-devel] Re: [PATCH] libxl: initialize domid 
to 0 in libxl__create_stubdom"):
> On Fri, 17 Jun 2011, Ian Jackson wrote:
> >    char *something = NULL;
> >    uint32_t domid = -1;
> > 
> >    ...
> >    something = allocate();
> >    if (!something) goto error_exit;
> >    ...
> >    ret = libxl__domain_make(&domid);
> >    if (ret) goto error_exit;
> >    ...
> > 
> >    return successfully somehow;
> > 
> >   error_exit:
> >    free(something);
> >    if (libxl_domid_valid_guest(domid))
> >        libxl_domain_destroy(domid);
...
> If we decide to make domid an output parameter only, then
> 
> uint32_t domid;
> 
> isn't a bug anymore.

Look at the code above.  Without the initialisation, if allocate()
returns NULL, it calls:
  libxl_domid_valid_guest(UNDEFINED)
If it's an output parameter only then neither valgrind nor the
compiler will ever spot this bug unless allocate() actually fails.

The arrangement with the caller initialising and the check in
libxl__domain_make is there to support this error-handling paradim
(which is a good paradigm because it means you don't have to carefully
match up allocations with frees on every error exit path), and which
tries to give us a chance of spotting missing initialisation bugs.

> Have you read http://marc.info/?l=xen-devel&m=130763064528133?

Yes.  I don't agree.

Ian.

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

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