Re: [Xen-devel] [PATCH v3 17/28] tools/libxl: Infrastructure for reading a libxl migration v2 stream

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/07/15 16:08, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH v3 17/28] tools/libxl: Infrastructure for 
> reading a libxl migration v2 stream"):
> ...
>> +static void write_emulator_blob(libxl__egc *egc,
>> +                                libxl__stream_read_state *stream,
>> +                                libxl__sr_record_buf *rec)
> ...
>> +    libxl__carefd_begin();
>> +    writefd = open(path, O_WRONLY | O_CREAT | O_TRUNC, 0600);
>> +    if (writefd == -1) {
>> +        rc = ERROR_FAIL;
>> +        LOGE(ERROR, "unable to open %s", path);
>> +        libxl__carefd_unlock();
>> +        goto err;
>> +    }
> I have just spotted something else which I think both of us missed
> from my review of v2:
>
> I wrote:
>
>     If [you keep using carefd for this], then please use
>     libxl__carefd_opened.  (Best would be to libxl__carefd_opened to
>     save and restore errno and then you can call it unconditionally
>     after the open.)
>
> I meant `best would be to _change_ libxl__carefd_opened save and
> restore errno'.
>
>> +    assert(stream->emu_carefd == NULL);
>> +    stream->emu_carefd = libxl__carefd_opened(CTX, writefd);
> And then call it _unconditionally_, _immediately after_ the open.
>
> This means that the carefd functions bracketing open are easy to see
> and there is no entanglement with error-handling flow control.

libxl__carefd_opened() doesn't tolerate being handed -1.  It cannot be
used ahead of the error check.

I could see about introducing something like libxl__carefd_open() as a
carefd wrapper to open(2)

~Andrew

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