Junio C Hamano <gitster@xxxxxxxxx> writes: >> We now abort the loop if inflate() returns Z_BUF_ERROR without >> consuming the entire input buffer it was given, or has filled >> the entire output buffer but has not yet returned Z_STREAM_END. >> Either state is a clear indicator that this loop is not working >> as expected, and should not continue. > > When the inflated contents is of size 0, avail_out would be 0 and avail_in > would still have something because the input stream needs to have the end > of stream marker that is more than zero byte long. After thinking about this a bit more, I am reasonably sure that this is it. The contents does not have to be a 0-length string, but you would hit this if the pure-data portion of the deflated stream aligns at the end of your (un)pack window and it happens to require another use_pack() to move the window to read the end-of-stream signal. In that situation, the output buffer has already been filled, but you haven't read the input stream fully. Would't the new check incorrectly trigger in such a case? >> st = git_inflate(&stream, Z_FINISH); >> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out)) >> + break; We won't see this on 64-bit platforms because we use larger (un)pack window and the condition is much less likely to be met. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html