Buffer sizes smaller than gzip header not handled properly #164
Description
If you create a gzip encoder with manual input and a buffer size smaller than 10, this line gets executed. This returns a status indicating that the input buffer can be overridden even though it has never been read.
This may seem like a small issue because it only occurs when there is very little data in the buffers. However, the existence of the check indicates that there is an intention to handle this edge case which currently does not work.
I think failing in these case would already be an improvement. However, supporting this case properly would also be helpful. Consider, for example, the case where we want to decompress a file with multiple gzip members. These members are concatenated which is valid according to the gzip specification, but currently not supported with this library. If you want to implement it still, you can easily end up in situations where one member occupies most of the buffer so that there are only few bytes left for the next members header. I have implemented this in this gist inspired by decompress.ml in this repo. There are workarounds for this like moving the data in the buffer and filling in the rest, but it would be nice if they weren't necessary.