| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__create_st
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
|
|
|
| |
|
Home