[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__create_stubdom
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |