SunOS 4.1 doesn't have memmove(), and there may be others. memcpy()
should not be used for overlapping copies, so here a simple copy is
implemented that works for the particular direction of the overlap,
which is where the destination precedes the source.
Also since gzread() will no longer return an error for an incomplete
gzip file, have gzclose() return an error if the last gzread() ended
in the middle of a gzip stream.
Z_BUF_ERROR was also being used for an unsuccessful gzungetc and for buffer
lengths that didn't fit in an int. Those uses were changed to Z_DATA_ERROR
in order to assure that Z_BUF_ERROR occurs only when a premature end of
input occurs, indicating that gzclearerr() can be used.
Before, gzeof() would return true (accurately) when the last read request
went just up to the end of the uncompressed data. In the analogous case,
feof() would return false, only returning true when a read request goes
past the end of the file. This patch corrects gzeof() to behave in the
same way as feof(), as noted in the zlib.h documentation.
Before this fix, gzread() would lose data if a premature end of file
was encountered. This prevented gzread() from being used on a file
that was being written concurrently. Now gzread() returns all of the
data it has available before indicating a premature end of file.
This also changes the error returned on a premature end of file from
Z_DATA_ERROR to Z_BUF_ERROR. This allows the user to determine if
the error is recoverable, which it is if Z_BUF_ERROR is returned. If
a Z_DATA_ERROR is returned, then the error is not recoverable.
This patch replaces the functionality of a previous patch that fixed
reading through an empty gzip stream in a concatenation of gzip
streams.
To implement this fix, a noticeable rewrite of gzread.c was needed.
The patch has the added advantage of using inflate's gzip processing
instead of replicating the functionality in gzread.c. This makes the
gz code a little simpler.
Previously the new gz* functions (introduced in 1.2.4) would read and
return raw data after the last gzip stream. This is inconsistent with
the behavior of gzip and the previous versions of zlib. Now when one
or more gzip streams have been decoded from the file, which is then
followed by data that is not a gzip stream (as detemined by not finding
the magic header), then that subsequent trailing garbage is ignored,
and no error is returned.
Mark Adler