On Friday 09 July 2010 22:59:06 Daniel Jacobowitz wrote: > On Fri, Jul 09, 2010 at 10:54:07PM +0400, Vladimir Prus wrote: > > On Wednesday 07 July 2010 20:29:55 Daniel Jacobowitz wrote: > > > > > > - if (xfer == 0) > > > > - return xfered; > > > > - if (xfer < 0) > > > > - { > > > > - remaining = half; > > > > - } > > > > - else > > > > - { > > > > - /* We have successfully read the first half. So, the > > > > - error must be in the second half. Adjust start and > > > > - remaining to point at the second half. */ > > > > - xfered += xfer; > > > > - start += xfer; > > > > - remaining -= xfer; > > > > - } > > > > - half = remaining/2; > > > > + xfree (buffer); > > > > + xfered += to_read; > > > > } > > > > > > Why do we skip to_read bytes if we succeed at reading zero bytes? > > > For that matter, what does a return value of zero mean? It seems like > > > this would mean the same as -1. > > > > I am not really sure. Per documentation of target_read: > > > > Return the number of bytes actually transfered, or -1 if the > > transfer is not supported or otherwise fails. Return of a positive > > value less than LEN indicates that no further transfer is possible. > > > > So, value of 0 seems to mean 'there are no more bytes that that, honest', > > and that we probably don't need to try further. Documentation for > > to_xfer_partial seem to give such meaning to return of 0. > > I'd suggest treating 0 and -1 the same, for memory. > > > On the > > other hand, it's not clear what return value of > and whether we should try to read remaining chunk. What would you suggest? > > A return of less than LEN from xfer_partial doesn't mean anything; you > just retry. A return of less than LEN from target_read, though, is > supposed to mean that there is no point in retrying; the next byte is > inaccessible or does not exist. > > It doesn't look like memory reads (unlike other partial transfers) > implement that; usually they just fail. But we can treat it that way > anyway. So see what happens after those successful bytes. Here's a revised version. Thanks, -- Vladimir Prus CodeSourcery vladimir@codesourcery.com (650) 331-3385 x722