Re: [Xen-devel] [PATCH] tools/libxl: Fix build following c/s c3c8da9

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 29/06/15 15:09, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] tools/libxl: Fix build following c/s c3c8da9"):
>> c/s c3c8da9 "libxl: ao: datacopier callback gets an rc" caused
>> libxl__domain_save_device_model() to pass its rc directly into the callback.
>>
>> However in the preexisting code, there were 3 "goto out;" paths which left rc
>> uninitialised, which is cause by GCC 4.8's -Wmaybe-uninitialized
> The solution is not to initialise rc (to a bogus value) but to fix the
> goto out paths to explicitly set rc.
>
> Can you easily confirm that this fixes it ?

It does indeed.  Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

However, the problem with this style is that it is subverted by:

rc = libxl__datacopier_start(dc);
if (rc) goto out;

out of context below, which cases rc to be initialised on all subsequent
error paths, and thus miss further issues where it is set incorrectly.

I would suggest introducing another int to hold the temporary from
libxl__datacopier_start().

~Andrew

>
> Ian.
>
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index bdc0465..1c9418a 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -2190,17 +2190,20 @@ void libxl__domain_save_device_model(libxl__egc *egc,
>      dc->readfd = open(filename, O_RDONLY);
>      if (dc->readfd < 0) {
>          LOGE(ERROR, "unable to open %s", dc->readwhat);
> +        rc = ERROR_FAIL;
>          goto out;
>      }
>  
>      if (fstat(dc->readfd, &st))
>      {
>          LOGE(ERROR, "unable to fstat %s", dc->readwhat);
> +        rc = ERROR_FAIL;
>          goto out;
>      }
>  
>      if (!S_ISREG(st.st_mode)) {
>          LOG(ERROR, "%s is not a plain file!", dc->readwhat);
> +        rc = ERROR_FAIL;
>          goto out;
>      }
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel