This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

<Prev in Thread] Current Thread [Next in Thread>