Don't allocate an obviously-too-large buffer for uncompressed data if
ISIZE becomes corrupted in a small file. This isn't too effective, as
we still must allow over 1000x expansion, but we might as well do this.
Update https://github.com/ebiggers/libdeflate/issues/157
The '-t' option of GNU gzip allows checking whether a gzip file is valid
without writing the data anywhere. It's relatively straightforward to
support in libdeflate-gzip too, so add support for it.
Resolves https://github.com/ebiggers/libdeflate/issues/125
[EB - updated commit message]
Avoid confusion with the GNU extension 'program_invocation_name', which
is described by 'man 3 program_invocation_name'. The GNU version isn't
supposed to be exposed without defining _GNU_SOURCE, which we don't in
any of the relevant files, but it's best to avoid any confusion.
Some users may require a valid DEFLATE, zlib, or gzip stream but know
ahead of time that particular inputs are not compressible. zlib
supports "level 0" for this use case. Support this in libdeflate too.
Resolves https://github.com/ebiggers/libdeflate/issues/86
libdeflate's 'gunzip' program fails if the uncompressed file size is a
nonzero multiple of 4 GiB because then the ISIZE field in the gzip file
is 0, so gunzip allocates no space for the decompressed data. Then when
libdeflate returns LIBDEFLATE_INSUFFICIENT_SPACE, gunzip doubles the
buffer size which stays 0, causing it to report "file corrupt or too
large to be processed by this program".
While neither libdeflate nor its 'gunzip' program is designed for single
gzip streams this large anyway, this particular bug can easily be fixed
by always allocating at least one byte for the decompressed data.
* Bring in common headers and program code from xpack project
* Move program code to programs/
* Move library code to lib/
* GNU89 and MSVC2010 compatibility
* Other changes
