Closed dralley closed 2 years ago
I think those comments are incorrect. It appears that the buf
within the struct itself does not, in fact, store transcoded bytes, it just stores bytes straight from the file. Decoding / transcoding happens in the Read
implementation when data is copied into the user-provided buffer.
However, despite not providing a BufRead
interface, am I correct in saying that it fulfills one of the primary purposes of using a BufReader
, which is avoiding the syscall overhead of repeated reads? So if you don't need the BufRead
interface, you don't need to wrap a BufReader
around the file?
You're correct that this cannot implement BufRead
on its own.
I believe you are also correct that the way this library is implemented, in generally means you don't need to pass a buffered reader to a DecodeReaderBytes
. You might want to wrap a DecodeReaderBytes
itself in a BufReader
though, to avoid the overhead of potentially calling the transcoding function a bunch of times on small inputs.
Some or all of this probably should be added to the docs.
Addressing the documentation in my open PR.
I might be missing something, but it seems like
DecodeReaderBytes
contains an internal buffer for transcoded bytesas well as a position in that buffer where reads start from, as well as an end of the transcoded bytes
Shouldn't it be possible to trivially implement
BufRead
on top of that without a needing external buffer (and hence, extra copying)?