|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__creat
On Fri, 17 Jun 2011, Ian Jackson wrote:
> 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.
If we decide to make domid an output parameter only, then
uint32_t domid;
isn't a bug anymore.
Have you read http://marc.info/?l=xen-devel&m=130763064528133?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|