| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] libxl: initialize domid to 0 in libxl__creat
On Tue, 21 Jun 2011, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] Re: [PATCH] libxl: initialize
> domid to 0 in libxl__create_stubdom"):
> > I understand what you mean, but in that case I would rather have the
> > check right before allocate:
> >
> > assert(!libxl_domid_valid_guest(*domid));
> > something = allocate();
> >
> > in the outer function.
>
> What? Are you proposing this:
>
> char *something = NULL;
> uint32_t domid = -1;
>
> ...
> assert(!libxl_domid_valid_guest(*domid));
> assert(!something);
> ...
>
> 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);
>
> What would be the point of that ?
>
For clarity I'll keep calling this function the "outer" function even
though there are no inner functions in this example.
The problem you are talking about is forgetting to initialize domid in
the outer function then jumping to error_exit because of an error in
allocate(), as a consequence libxl_domid_valid_guest is called passing
an UNDEFINED argument. Am I right?
This problem is caused by the way the outer function is coded and should not
affect the way other functions are coded.
I don't think that editing other independent functions is a good way of
making the outer function more resilient.
The specific problem you mentioned can be solved by simply initializing
domid in the outer function.
If you would like a double check you can introduce an assert in the
outer function; libxl__domain_make is not the right place for it.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home