A massively spiffy yet delicately unobtrusive compression library.

Related tags

Compression zlib
Overview
ZLIB DATA COMPRESSION LIBRARY

zlib 1.2.11 is a general purpose data compression library.  All the code is
thread safe.  The data format used by the zlib library is described by RFCs
(Request for Comments) 1950 to 1952 in the files
http://tools.ietf.org/html/rfc1950 (zlib format), rfc1951 (deflate format) and
rfc1952 (gzip format).

All functions of the compression library are documented in the file zlib.h
(volunteer to write man pages welcome, contact [email protected]).  A usage example
of the library is given in the file test/example.c which also tests that
the library is working correctly.  Another example is given in the file
test/minigzip.c.  The compression library itself is composed of all source
files in the root directory.

To compile all files and run the test program, follow the instructions given at
the top of Makefile.in.  In short "./configure; make test", and if that goes
well, "make install" should work for most flavors of Unix.  For Windows, use
one of the special makefiles in win32/ or contrib/vstudio/ .  For VMS, use
make_vms.com.

Questions about zlib should be sent to <[email protected]>, or to Gilles Vollant
<[email protected]> for the Windows DLL version.  The zlib home page is
http://zlib.net/ .  Before reporting a problem, please check this site to
verify that you have the latest version of zlib; otherwise get the latest
version and check whether the problem still exists or not.

PLEASE read the zlib FAQ http://zlib.net/zlib_faq.html before asking for help.

Mark Nelson <[email protected]> wrote an article about zlib for the Jan.  1997
issue of Dr.  Dobb's Journal; a copy of the article is available at
http://marknelson.us/1997/01/01/zlib-engine/ .

The changes made in version 1.2.11 are documented in the file ChangeLog.

Unsupported third party contributions are provided in directory contrib/ .

zlib is available in Java using the java.util.zip package, documented at
http://java.sun.com/developer/technicalArticles/Programming/compression/ .

A Perl interface to zlib written by Paul Marquess <[email protected]> is available
at CPAN (Comprehensive Perl Archive Network) sites, including
http://search.cpan.org/~pmqs/IO-Compress-Zlib/ .

A Python interface to zlib written by A.M. Kuchling <[email protected]> is
available in Python 1.5 and later versions, see
http://docs.python.org/library/zlib.html .

zlib is built into tcl: http://wiki.tcl.tk/4610 .

An experimental package to read and write files in .zip format, written on top
of zlib by Gilles Vollant <[email protected]>, is available in the
contrib/minizip directory of zlib.


Notes for some targets:

- For Windows DLL versions, please see win32/DLL_FAQ.txt

- For 64-bit Irix, deflate.c must be compiled without any optimization. With
  -O, one libpng test fails. The test works in 32 bit mode (with the -n32
  compiler flag). The compiler bug has been reported to SGI.

- zlib doesn't work with gcc 2.6.3 on a DEC 3000/300LX under OSF/1 2.1 it works
  when compiled with cc.

- On Digital Unix 4.0D (formely OSF/1) on AlphaServer, the cc option -std1 is
  necessary to get gzprintf working correctly. This is done by configure.

- zlib doesn't work on HP-UX 9.05 with some versions of /bin/cc. It works with
  other compilers. Use "make test" to check your compiler.

- gzdopen is not supported on RISCOS or BEOS.

- For PalmOs, see http://palmzlib.sourceforge.net/


Acknowledgments:

  The deflate format used by zlib was defined by Phil Katz.  The deflate and
  zlib specifications were written by L.  Peter Deutsch.  Thanks to all the
  people who reported problems and suggested various improvements in zlib; they
  are too numerous to cite here.

Copyright notice:

 (C) 1995-2017 Jean-loup Gailly and Mark Adler

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
     claim that you wrote the original software. If you use this software
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

  Jean-loup Gailly        Mark Adler
  [email protected]          [email protected]

If you use the zlib library in a product, we would appreciate *not* receiving
lengthy legal documents to sign.  The sources are provided for free but without
warranty of any kind.  The library has been entirely written by Jean-loup
Gailly and Mark Adler; it does not include third-party code.

If you redistribute modified sources, we would appreciate that you include in
the file ChangeLog history information documenting your changes.  Please read
the FAQ for more information on the distribution of modified source versions.
Issues
  • CVE-2018-25032 (zlib memory corruption on deflate)

    CVE-2018-25032 (zlib memory corruption on deflate)

    CVE-2018-25032 tracks a bug in zlib 1.2.11 which allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.

    There is a fix from @madler at https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

    @taviso reports at https://www.openwall.com/lists/oss-security/2022/03/24/1 that this patch never made it into a release, and at the time of writing no distros had picked it up as a fix.

    opened by vielmetti 29
  • Processing ZIP files in Java broken with latest zlib

    Processing ZIP files in Java broken with latest zlib

    After the upgrade to macOS High Sierra several Java applications that compress data stopped working correctly. Example are KNIME Analytics Platform or Tomcat. I was able to track down the problem to a potential bug in the zlib version shipped with High Sierra (1.12.11). Version 1.2.5 which is used in Sierra works find. The bug is caused by changing the compression levels for different entries. CreateZip.java.txt (rename to .java) demonstrates the problem. Compile and start with /tmp 100 as arguments. It works fine on any operating system except macOS High Sierra. If you comment the three lines that are marked with "Triggers the bug" the program also works as expected. This is a blocker for any Java application that changes compression levels on macOS therefore please consider this a critical bug.

    opened by sithmein 28
  • NEON implementation for Adler32

    NEON implementation for Adler32

    The checksum is calculated in the uncompressed PNG data and can be made much faster by using SIMD.

    Tests in ARMv8 yielded an improvement of about 3x (e.g. walltime was 350ms x 125ms for 4096x4096 bytes executed 30 times). That results in at least 18% improvement in PNG image decoding in Chromium.

    Further details at: https://bugs.chromium.org/p/chromium/issues/detail?id=688601

    opened by Adenilson 28
  • Zlib: deflateEnd() fails after deflateInit2()/deflateReset() when initialized for

    Zlib: deflateEnd() fails after deflateInit2()/deflateReset() when initialized for "Raw Deflate Compression"

    Description of the problem is:

    deflateInit () for raw deflate moves internal state to BUSY_STATE (where as it is INIT_STATE for zlib). BUSY_STATE is considered to be == INIT_STATE for raw deflate. So, when deflateEnd() is called, it has no way to identify whether stream is in the start or middle of core deflate operation() thus reports an Z_DATA_ERROR.

    How does it affect:

    //This will work: deflateInit2() deflate(strmp,Z_FINISH); deflateEnd()

    //This will not work deflateInit2() while(cnt—) { deflate(strmp,Z_FINISH); deflateReset()<--required to re-initiate deflate() on next input. } deflateEnd();

    test_def_init_term.c - a simple test case to reproduce issue.

    opened by 1234sv 20
  • gzseek broken on uncompressed streams on Windows

    gzseek broken on uncompressed streams on Windows

    On Windows, when calling gzopen on a plain text file, reading some bytes (at least 1), then calling gzseek(f, 0L, SEEK_SET), all subsequent gzread calls fail (they return 0).

    This does not happen when opening a compressed stream.

    In contrast, calling gzrewind(f) (which should be equivalent to the above, according to the documentation in "zlib.h") always works. Also, on Linux and MacOSX there is no such issue.

    I'm using zlib 1.2.8, and Windows 7 32bit (but I believe 64bit is also affected).

    Here is a simple test file which shows the problem (assuming "tst.tmp.txt" is any plain text file):

    #include <stdio.h>
    #include <zlib.h>
    
    int main(int argc,char *argv[])
    {
        char buf[1000];
        int ret;
        gzFile f = gzopen("tst.tmp.txt", "rb");
        //gzFile f = gzopen("tst.tmp.gz", "rb"); // this works
    
        while (!gzeof(f)) {
            ret = gzread(f, buf, 1);
            if (!ret) {
                printf("READ FAILED\n");
            } else {
                printf("%c %i\n", buf[0], buf[0]);
            }
        }
        printf("EOF\n");
        ret = gzseek(f, 0, SEEK_SET);
        printf("SEEK RETURNED: %i\n", ret);
        while (!gzeof(f)) {
            ret = gzread(f, buf, 1);
            if (!ret) {
                printf("READ FAILED\n");
            } else {
                printf("%c %i\n", buf[0], buf[0]);
            }
        }
        printf("EOF\n");
    
        return 0;
    }
    

    when running the code, the first while loop succeeds, then gzseek returns 0, and subsequent gzreads fail. If the first while loop is omitted, the rest succeeds, but as long as a single byte is read the bug is observed.

    opened by carlobaldassi 20
  • Deflate failures confirmed in downstreams using 1.2.10 / 1.2.11

    Deflate failures confirmed in downstreams using 1.2.10 / 1.2.11

    Sorry this is not a more helpful bug report as I don't know the nature of the issue or have a simple test program but I thought I should leave it here in case it helps others.

    I found a problem this week in the Erlang dialyzer program on Arch Linux; it was not able to recognize its own file formats after an update. I isolated the failure to the recent zlib update and then found someone else from the Arch forum had also found a zlib problem in an SDL game.

    @michelboaventura had also seen the dialyzer issue using 1.2.11 on gentoo, after hearing it was linked to zlib he was kind enough to bisect the zlib commit history and isolated the fault to b516b4bdd7c0c9f0858adfebf732089014f7b282 (this is reported in this thread). The same commit was confirmed to be where the issue was introduced in the manaplus game mentioned in the Arch thread.

    opened by jeremyjh 16
  • Flyway migrations CRC32 checksum different after upgrading to 1.2.12 (from 1.2.11)

    Flyway migrations CRC32 checksum different after upgrading to 1.2.12 (from 1.2.11)

    There are multiple projects that rely on this library. In my case it is Flyway migrations that is using it to calculate checksum. 2 days ago it started producing different values for CRC32 what caused app crash on startup. It seems your recent release is not backwards compatible and shouldn't be a patch. Please verify it.

    opened by nmapx 14
  • zlib 1.2.8 always uses Windows 8 - level API

    zlib 1.2.8 always uses Windows 8 - level API

    When compiled with VS2012, zlib ends up always using Windows 8 level API, e.g.: CreateFile2().

    Looking at the code, I see that this regression has been introduced in the following commit: 5481269e1fa6d99a1

    More specifically, the define on line 31 always defines IOWIN32_USING_WINRT_API. That happens because WINAPI_FAMILY_PARTITION is defined, even on Windows 7.

    I use Windows 7 and Visual Studio 2012 and experience errors since the library don't work (missing methods in kernel32.dll).

    opened by Tvangeste 14
  • Failed to find a pointer-size integer type.

    Failed to find a pointer-size integer type.

    I am getting this error:

    Unpacking download/zlib-1.2.11.tar.gz to build/zlib/ios-x86_64... Using ar Building static library libz.a version 1.2.11 with clang. Checking for size_t... No. Checking for long long... Yes. Failed to find a pointer-size integer type. ** ./configure aborting.

    opened by adyshimony 13
  • deflate bug with windowBits == 8?

    deflate bug with windowBits == 8?

    What's all this about?

        if (windowBits == 8) windowBits = 9;  /* until 256-byte window bug fixed */
    

    https://github.com/madler/zlib/blob/master/deflate.c#L276

    Does this mean that 256-byte windows are broken?

    opened by vinniefalco 13
  • Read access violation in inffas32.asm on Win32 build

    Read access violation in inffas32.asm on Win32 build

    There is a read access violation in mentioned file. It's on line 669.

    My setup: -Visual Studio 2015 Community -Zlib 1.2.11 sources.

    I downloaded sources compiled library with projects in contrib/vstudio/vc14. Then I linked it to my own project. When i try to run zpipe.c example in x86(win32) there is read access violation. On x64 it works completely fine, both debug and release. This happen on only decompresion. I managed to compress some file with this library that I build. On run I just redirect that compressed file to stdin. My project is c++ if it can change something.

    opened by ketjow4 12
  • Please make new release

    Please make new release

    @madler: It is possible to release a new build with all build fixes...? A 1.2.12.1 or 1.2.13?

    It is really important to have a solution to current 1.2.12.

    Tickets/PRs:

    • https://github.com/madler/zlib/issues/404
    • https://github.com/madler/zlib/issues/604
    • https://github.com/madler/zlib/pull/607
    • https://github.com/madler/zlib/issues/608
    • https://github.com/madler/zlib/issues/609
    • https://github.com/madler/zlib/issues/613
    • https://github.com/madler/zlib/pull/614
    • https://github.com/madler/zlib/issues/615
    • https://github.com/madler/zlib/issues/617
    • https://github.com/madler/zlib/issues/618
    • https://github.com/madler/zlib/issues/620 + https://github.com/Esri/zlib/commit/05b33dd27dbbfc9360d5c2430e228d7dc48f92f6
    • https://github.com/madler/zlib/issues/622
    • https://github.com/madler/zlib/issues/623
    • https://github.com/madler/zlib/issues/628
    • https://github.com/madler/zlib/issues/629
    • https://github.com/madler/zlib/issues/631
    • https://github.com/madler/zlib/pull/632
    • https://github.com/madler/zlib/issues/635
    • https://github.com/madler/zlib/pull/638
    • https://github.com/madler/zlib/pull/639
    • https://github.com/madler/zlib/pull/644
    • https://github.com/madler/zlib/pull/645
    • https://github.com/madler/zlib/issues/646
    • https://github.com/madler/zlib/issues/660
    • https://github.com/madler/zlib/issues/661
    • https://github.com/madler/zlib/pull/662
    • https://github.com/madler/zlib/issues/672

    Thanks in advance.

    Linked to:

    • https://github.com/madler/zlib/issues/422

    cc: @gvollant.

    opened by Neustradamus 2
  • Incorrect build flag (-DPIC) in Makefile.in

    Incorrect build flag (-DPIC) in Makefile.in

    The 1.2.12 build fails to link on Linux x64 (specifically, Mint 20.3 with clang 10) because the build uses -DPIC instead of -fPIC. Insofar as i grep can see, there is no macro named "PIC" used by the source files, so this appears to be a typo in Makefile.in. Globally replacing -DPIC with -fPIC fixes the build.

    opened by sgbeal 0
  • cross-building with MinGW (on Ubuntu 21.10) fails due to temporary workaround

    cross-building with MinGW (on Ubuntu 21.10) fails due to temporary workaround

    Hi, I am preparing a cross-build environment for NUT using Ubuntu mingw-w64 package, and along the chain of dependencies there is zlib.

    Its current (1.2.12) configure script includes this "temporary bypass" which seems toxic for cross-builds (probably was added to help someone with native builds?):

      MINGW* | mingw*)
    # temporary bypass
            rm -f $test.[co] $test $test$shared_ext
            echo "Please use win32/Makefile.gcc instead." | tee -a configure.log
            leave 1
            LDSHARED=${LDSHARED-"$cc -shared"}
            LDSHAREDLIBC=""
            EXE='.exe' ;;
    

    While I can run make win32/Makefile.gcc it fails due to... whatever (did not debug much); however commenting away leave 1 and building with:

    CHOST="$ARCH" ./configure --prefix=/usr/$ARCH
    

    where ARCH="i686-w64-mingw32" or ARCH="x86_64-w64-mingw32" it "just works" so I did not dig further.

    Probably an option would be in order here (user-defined or guessed from env) to decide whether to leave or proceed.

    opened by jimklimov 0
  • Potential issue with compression function

    Potential issue with compression function

    Hi,

    I noticed a problem in version 1.2.11 when I try to interact with python basically if I run:

    CASE 1: compress(compress_data, &destLen, (uint8_t *)message, wr_len) wr_len is ignored, if the full buffer is 74kB, extra zero are sent and when python tries to decode with zlib.decompress(message) it reads garbage data as a buffer overflow

    CASE 2: compress2(compress_data, &destLen, (uint8_t *)message, wr_len, -1) that works like a charm even for big buffer and the file is decoded correctly

    Please let me know if u need more information, thanks!

    opened by HDenied 1
  • minizip: use default variables/rules in Makefile

    minizip: use default variables/rules in Makefile

    The minizip bare Makefile overrides CC/CFLAGS and the default compile/link rules for no reason, which breaks users who want to pass specific CFLAGS/LDFLAGS.

    These can all be removed: the out-of-box build is unchaged but overriding CFLAGS or LDFLAGS now works as expected.

    opened by rossburton 0
Owner
Mark Adler
Mostly harmless.
Mark Adler
LZFSE compression library and command line tool

LZFSE This is a reference C implementation of the LZFSE compressor introduced in the Compression library with OS X 10.11 and iOS 9. LZFSE is a Lempel-

null 1.7k Jul 30, 2022
Small strings compression library

SMAZ - compression for very small strings ----------------------------------------- Smaz is a simple compression library suitable for compressing ver

Salvatore Sanfilippo 990 Jul 27, 2022
A simple C library implementing the compression algorithm for isosceles triangles.

orvaenting Summary A simple C library implementing the compression algorithm for isosceles triangles. License This project's license is GPL 2 (as of J

Kevin Matthes 0 Apr 1, 2022
Advanced DXTc texture compression and transcoding library

crunch/crnlib v1.04 - Advanced DXTn texture compression library Public Domain - Please see license.txt. Portions of this software make use of public d

null 747 Jul 19, 2022
Brotli compression format

SECURITY NOTE Please consider updating brotli to version 1.0.9 (latest). Version 1.0.9 contains a fix to "integer overflow" problem. This happens when

Google 11.3k Aug 2, 2022
Extremely Fast Compression algorithm

LZ4 - Extremely fast compression LZ4 is lossless compression algorithm, providing compression speed > 500 MB/s per core, scalable with multi-cores CPU

lz4 7.4k Aug 6, 2022
Zstandard - Fast real-time compression algorithm

Zstandard, or zstd as short version, is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better comp

Facebook 17.4k Aug 8, 2022
Lossless data compression codec with LZMA-like ratios but 1.5x-8x faster decompression speed, C/C++

LZHAM - Lossless Data Compression Codec Public Domain (see LICENSE) LZHAM is a lossless data compression codec written in C/C++ (specifically C++03),

Rich Geldreich 628 Jul 28, 2022
A bespoke sample compression codec for 64k intros

pulsejet A bespoke sample compression codec for 64K intros codec pulsejet lifts a lot of ideas from Opus, and more specifically, its CELT layer, which

logicoma 34 Jul 25, 2022
A variation CredBandit that uses compression to reduce the size of the data that must be trasnmitted.

compressedCredBandit compressedCredBandit is a modified version of anthemtotheego's proof of concept Beacon Object File (BOF). This version does all t

Conor Richard 17 Apr 9, 2022
Data compression utility for minimalist demoscene programs.

bzpack Bzpack is a data compression utility which targets retrocomputing and demoscene enthusiasts. Given the artificially imposed size limits on prog

Milos Bazelides 20 Jul 27, 2022
gzip (GNU zip) is a compression utility designed to be a replacement for 'compress'

gzip (GNU zip) is a compression utility designed to be a replacement for 'compress'

ACM at UCLA 7 Apr 27, 2022
Better lossless compression than PNG with a simpler algorithm

Zpng Small experimental lossless photographic image compression library with a C API and command-line interface. It's much faster than PNG and compres

Chris Taylor 201 Jun 28, 2022
A C++ static library offering a clean and simple interface to the 7-zip DLLs.

bit7z A C++ static library offering a clean and simple interface to the 7-zip DLLs Supported Features • Getting Started • Download • Requirements • Bu

Riccardo 279 Jul 29, 2022
miniz: Single C source file zlib-replacement library, originally from code.google.com/p/miniz

Miniz Miniz is a lossless, high performance data compression library in a single source file that implements the zlib (RFC 1950) and Deflate (RFC 1951

Rich Geldreich 1.5k Aug 8, 2022
Fork of the popular zip manipulation library found in the zlib distribution.

minizip-ng 3.0.0 minizip-ng is a zip manipulation library written in C that is supported on Windows, macOS, and Linux. Developed and maintained by Nat

zlib-ng 926 Jul 26, 2022
Fork of the popular zip manipulation library found in the zlib distribution.

minizip-ng 3.0.1 minizip-ng is a zip manipulation library written in C that is supported on Windows, macOS, and Linux. Developed and maintained by Nat

zlib-ng 929 Aug 5, 2022
PhysFS++ is a C++ wrapper for the PhysicsFS library.

PhysFS++ PhysFS++ is a C++ wrapper for the excellent PhysicsFS library by Ryan C. Gordon and others. It is licensed under the zlib license - same as P

Kevin Howell 78 May 17, 2022
An embedded-friendly library for decompressing files from zip archives

An 'embedded-friendly' (aka Arduino) library to extract and decompress files from ZIP archives

Larry Bank 25 Jul 17, 2022