Re: [patch/rfc] to_read/write_partial -> to_xfer_partial

[Andrew Cagney <ac131313 at redhat dot com>]

> On Oct 27,  3:25pm, Andrew Cagney wrote:
>
>
> > Per: http://sources.redhat.com/ml/gdb-patches/2003-10/msg00641.html
>
> > > Having taken the change to this point, I'm now wondering if the read/write partial methods should be merged into:
> > > to_xfer_partial (targ, object, annex,
> > > offset, len,
> > > readbuf, writebuf)
> > > as that would make migrating existing targets easier.
>
> > Having implemented bfd-target and remote-target versions 
> > to_read/write_partial, I think this switch is going to make life easier. 
>
>
> Could you offer a few more details on why you think that merging the
> read/write methods into a single xfer method will make it easier to
> migrate existing targets?

There's a tradeoff.  You'll notice that I started out with separate 
asthetically pleasing read/write methods, but eventually decided the 
cost was too high.

- the existing targets implement a memory centric "xfer".  Its going to 
be easier [for me] to convert that code to this new xfer variant.

- both the read and write paths use identical buffer overflow logic, and 
its that logic which contains the nasty edge cases and consequent bugs. 
 Compare target_read and target_write:

  LONGEST xfered = 0;
  while (xfered < len)
    {
      LONGEST xfer = target_read_partial (ops, object, annex,
                                          (bfd_byte *) buf + xfered,
                                          offset + xfered, len - xfered);
      /* Call an observer, notifying them of the xfer progress?  */
      if (xfer <= 0)
        /* Call memory_error?  */
        return -1;
      xfered += xfer;
      QUIT;
    }
  return len;

and

  LONGEST xfered = 0;
  while (xfered < len)
    {
      LONGEST xfer = target_write_partial (ops, object, annex,
                                           (bfd_byte *) buf + xfered,
                                           offset + xfered, len - xfered);
      /* Call an observer, notifying them of the xfer progress?  */
      if (xfer <= 0)
        /* Call memory_error?  */
        return -1;
      xfered += xfer;
      QUIT;
    }
  return len;

In testing this interface I had to fix similar but not identical bugs in 
both paths.

- If this were OO, I'd be doing it differently :-/

- unlike the memory xfer method, this one takes an explicit read and 
write buffer - the problem of casting away "const" is avoided.

- the core code doesn't need to be aware of this target internal detail, 
continuing to use more sane read/write methods.

enjoy,
Andrew