[libvirt] [PATCH] avoid a probable EINVAL from lseek

[Jim Meyering]

Daniel P. Berrange wrote:
> On Tue, Feb 02, 2010 at 10:37:32AM +0100, Jim Meyering wrote:
>> Daniel P. Berrange wrote:
>>
>> > On Mon, Feb 01, 2010 at 10:18:27PM +0100, Jim Meyering wrote:
>> >>
>> >> In src/qemu/qemu_driver.c, coverity reports this:
>> >>
>> >>   Event negative_return_fn: Called negative-returning function "lseek(logfile, 0L, 2)"
>> >>   Event var_assign: NEGATIVE return value of "lseek" assigned to signed variable "pos"
>> >>   At conditional (1): "(pos = lseek(logfile, 0L, 2)) < 0" taking true path
>> >>   2877 	    if ((pos = lseek(logfile, 0, SEEK_END)) < 0)
>> >>   2878 	        VIR_WARN(_("Unable to seek to end of logfile: %s"),
>> >>   2879 	                 virStrerror(errno, ebuf, sizeof ebuf));
>> >
>> > I think it'd be less surprising to just set 'pos = 0' inside the if
>> > branch here, so later code doesn't have to worry about unexpected
>> > negative values.
>>
>> Oh.  I pushed after DV's ACK.
>>
>> That would let the later code continue, but using (lseek'ing to) an
>> invalid position.  Sounds like it could result in a cascade of
>> additional errors, or worse, silent malfunction.
>
> The code which later uses this 'pos'  variable, does so in order to skip
> over the start of the logfile which it does not want. So by setting pos=0
> we make it start at the beginning of the file instead.

Wouldn't that result in reprocessing (misleadingly) past diagnostics?

>> But this is largely hypothetical, since failing to lseek-to-EOF
>> on a valid file descriptor is not likely to happen.
>
> My reasoning is that putting the 'pos < 0' check in another separate
> method far away from where the error occurs is rather obscure, and
> the kind of code that will likely be deleted by mistake in later
> refactoring.

I agree that this action-at-a-distance is bad.
I can add a comment pointing to this discussion.

Or,... considering that this type of failure is so unlikely,
would you prefer to make the initial lseek evoke failure
rather than just a warning?