[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__create_stubdom
Ian Campbell writes ("[Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__create_stubdom"): > Yeah, me too, that line could just be hoisted up to the first thing the > function does with no loss of safety AFAICT. The question is really what the error handling pattern is expected to be in the caller. Our usual error handling pattern (which I think is a good one) is something like: 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 expect callers of libxl__domain_make to do this with the domid then there is no benefit to doing the initialisation in libxl__domain_make; indeed doing so would just mask failure-to-initialise bugs in the caller - bugs which the compiler can't spot. Defining the interface to libxl__domain_make to _not_ initialise the value means that the bug of writing uint32_t domid; rather than uint32_t domid = -1; can be detected by valgrind at least and also standds a chance of failing the assertion. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |