[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.