[rfa] Add the bfd_iovec

[Andrew Cagney]

Ok, the attached should differ by the original by:

- removing ->berror()

- adding a description of each b*() method
The interface doesn't treat EOF as an error, and -1 is always an error 
indication.

- setting bfd_error when there's an error

Having done this, I'm wondering if setting bfd_error is all that useful. 
  You'll notice that the interfaces now all consistently return -1 and 
set bfd_error_system_call when there's an error.  I guess the memory 
IOVEC will get the chance to set bfd_error_no_memory.

anyway, ok?
Andrew


>>>>>>>> >>>> > * I'm not crazy about the berror entry point.  Right now it is used in
>>>>>>>> >>>> >   exactly one place, to indicate whether a short read is an error or
>>>>>>>> >>>> >   simply a truncated file.  Since bfd_iovec is only going to be called
>>>>>>>> >>>> >   by BFD routines, I think it would be quite reasonable to make the
>>>>>>>> >>>> >   bread entry point responsible for calling bfd_set_error.  Then the
>>>>>>>> >>>> >   caller does not need to go back in to find out what a short read
>>>>>>>> >>>> >   means.  Note also that berror is the only function which doesn't
>>>>>>>> >>>> >   have an obvious mapping to a Unix system call.
>>>>
>>>>> >>
>>>>
>>>>>> >>> There are three cases here:
>>>>>> >>> - error
>>>>>> >>> - eof
>>>>>> >>> - partial read (as in the next read should yield more data)
>>>>>> >>> I guess BFD isn't set up for partial transfers and retrys so the
>>>>>> >>> third
>>>>>> >>> case doesn't apply?
>>>
>>>> > Yes.  Or, to put it another way, the bread routine should be
>>>> > responsible for handling partial reads, if they are possible for the
>>>> > underlying I/O structure.
>>
>>> 
>>> Which leads to the next question, what should that return value be?
>>> read(2) or fread(3) or ??? semantics?  At present it is system
>>> dependant (see the #ifdef code in cache_bread in my patch).
> 
> 
> I would say that it should be whatever seems most useful.  Probably it
> should return number of bytes read, or -1 on error, with a short count
> indicating EOF.
> 
> As you say, the return value of the current real_read() differs in the
> error case.  That is a lurking bug.  It happens to not matter at
> present, given the way the return value is used in the only call.
> 
> Ian
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <https://sourceware.org/pipermail/binutils/attachments/20040414/7fc37616/attachment.ksh>