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

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?