I'm using the rust-lzma crate. It seems to possible, that its writer does not need to consume any of the input but needs to write data. Thus in the current implementation it returns zero bytes written. Which means write_all will fail with an error
(I'm not sure if this is an error in the implementation of the crate, though)
Generally, the implementation of write_all does not supports the case, where a writer consumes none of the input stream but needs to write some internally buffered data. So it seems to me, that using the number of bytes written as an error indicator is rather limiting. Or am I missing something?
I don't know since I'm not familiar with the internals of liblzma.
Is this kind of behaviour in general considered a bug?
I'm not sure if this is a correct behaviour or a bug in the rust-lzma crate. But for some reason this case is possible.
My hunch is it's a bug in the rust-lzma library. Caller requested that the entire buffer be written - write_all does not return until that's done unless there's an error. It doesn't sound like there's an error here, just lzma wants to write some internal data first. But then rust-lzma should drive liblzma to consume (write) the input buffer as well.
So a solution is probably for rust-lzma to provide its own impl of write_all rather than reusing the default. The default write_all looks to be intended for channels that can at least "sip" from the buffer - they may not be able to write the whole thing in 1 go, but can make steady progress (> 0 bytes) on each iteration. If the underlying channel may return 0 bytes "spuriously", then the Write impl for it needs to provide its own write_all that accounts for that.