Re: [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__create_stubdom

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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