Probably in practice the passed in objects are one of the buffered types where the read() behaves as this code obviously expected, which is likely why this hasn't been noticed before. However, we can't actually *know* that, and anything with a read() method would actually be perfectly valid. So it seems like a good patch to me.
However, svn_stream_t "full read" functions are obligated to return the
number of bytes requested, unless EOF.
Therefore, do we need the following patch?
swig-py: Support raw binary file-like objects for readable svn_stream_t*
(svn_swig_py_make_stream): Declare read_handler_pyio() as a non-full
svn_read_fn_t, in case PY_IO is a raw binary file object.
> On Wed, Jan 3, 2018 at 10:55 PM Daniel Shahaf <[hidden email]>
>> svn_swig_py_make_stream() is a function that wraps a PyObject in an
>> svn_stream_t. Its read implementation, read_handler_pyio(), just calls
>> the PyObject's .read() method.
>> According to <https://docs.python.org/2/library/io.html#io.RawIOBase.read >>> ,
>> the read() method of "raw" file-like objects makes only one read(2)
>> syscall, and so may return fewer bytes than were requested. (The py3
>> docs are similar.)
> Probably in practice the passed in objects are one of the buffered types
> where the read() behaves as this code obviously expected, which is likely
> why this hasn't been noticed before. However, we can't actually *know*
> that, and anything with a read() method would actually be perfectly valid.
> So it seems like a good patch to me.
I agree. Though not buffered streams but files; reading from a file will
always behave as a full read whilst reading from a socket or pipe or
fifo will not.
Anyway +1 for the patch. The full-read functionality is simulated at the
stream API implementation level if there's no specific full-read function.