Subversion Repositories Kolibri OS

http://zlib.net/ which may have more recent information.

The lastest zlib FAQ is at http://zlib.net/zlib_faq.html

    file win32/DLL_FAQ.txt in the zlib distribution.  Pointers to the

    precompiled DLL are found in the zlib web site at http://zlib.net/ .

        * http://marknelson.us/1997/01/01/zlib-engine/

        * win32/DLL_FAQ.txt in the zlib distribution

    buffer is equal to the available size of the compressed buffer and not

    zero.  For Visual Basic, check that this parameter is passed by reference

    ("as any"), not by value ("as long").

    When setting the parameter flush equal to Z_FINISH, also make sure that

    avail_out is big enough to allow processing all pending input.  Note that a

    Z_BUF_ERROR is not fatal--another call to deflate() or inflate() can be

    made with more input or output space.  A Z_BUF_ERROR may in fact be

    unavoidable depending on how the functions are used, since it is not

    possible to tell whether or not there is more output pending when

    strm.avail_out returns with zero.  See http://zlib.net/zlib_how.html for a

    heavily annotated example.

    and test/minigzip.c, with more in examples/ .

    zlib is rather portable and doesn't need much configuration.

    Please try to reproduce the problem with a small program and send the

    corresponding source to us at zlib@gzip.org .  Do not send multi-megabyte

    data files without prior agreement.

    /usr/X11R6/lib. Remove any old versions, then do "make install".

    distribution.

    the code of uncompress on your own.

    ./configure

    make

    Before going to the trouble of compiling a shared version of zlib and

    trying to install it, you may want to check if it's already there!  If you

    can #include , it's there.  The -lz option will probably link to

    it.  You can check the version at the top of zlib.h or with the

    ZLIB_VERSION symbol defined in zlib.h .

    site: Joel Hainley, jhainley@myndkryme.com.

    http://sourceforge.net/projects/acroformtool/ .

    generates an error such as:

        symbol __register_frame_info: referenced symbol not found

    the C compiler (cc or gcc).  You must recompile applications using zlib

    which have this problem.  This problem is specific to Solaris.  See

    http://www.sunfreeware.com for Solaris versions of zlib and applications

    using zlib.

    is different and incompatible with the gzip format.  The gz* functions in

    zlib on the other hand use the gzip format.  Both the zlib and gzip formats

    use the same compressed data format internally, but have different headers

    and trailers around the compressed data.

    single file, such as the name and last modification date.  The zlib format

    on the other hand was designed for in-memory and communication channel

    applications, and has a much more compact header and trailer and uses a

    faster integrity check than gzip.

    format using deflateInit2().  You can also request that inflate decode the

    gzip format using inflateInit2().  Read zlib.h for more details.

    provided memory allocation routines must also be thread-safe.  zlib's gz*

    functions use stdio library routines, and most of zlib's functions use the

    library memory allocation routines by default.  zlib's *Init* functions

    allow for the application to provide custom memory allocation routines.

    single thread at a time.

    what exactly do I need to do to meet that requirement?

    particular, the final version number needs to be changed to "f", and an

    identification string should be appended to ZLIB_VERSION.  Version numbers

    x.x.x.f are reserved for modifications to zlib by others than the zlib

    maintainers.  For example, if the version of the base zlib you are altering

    is "1.2.3.4", then in zlib.h you should change ZLIB_VERNUM to 0x123f, and

    ZLIB_VERSION to something like "1.2.3.f-zachary-mods-v3".  You can also

    update the version strings in deflate.c and inftrees.c.

    nature of the changes in zlib.h, as well as in ChangeLog and README, along

    with the dates of the alterations.  The origin should include at least your

    name (or your company's name), and an email address to contact for help or

    issues with the library.

    zconf.h is also a source distribution, and so you should change

    ZLIB_VERSION and ZLIB_VERNUM and note the origin and nature of the changes

    in zlib.h as you would for a full source distribution.

    exchange compressed data between them?

    data types being limited to 32-bits in length.  If you have any

    difficulties, please provide a complete problem report to zlib@gzip.org

    does PKZIP and zlib.  However, you can look in zlib's contrib/blast

    directory for a possible solution to your problem.

    Z_FULL_FLUSH, carefully write all the pending data at those points, and

    keep an index of those locations, then you can start decompression at those

    points.  You have to be careful to not use Z_FULL_FLUSH too often, since it

    can significantly degrade compression.  Alternatively, you can scan a

    deflate stream once to generate an index, and then use that index for

    random access.  See examples/zran.c .

    were working ports of zlib 1.1.4 to MVS, but those links no longer work.

    If you know of recent, successful applications of zlib on these operating

    systems, please let us know.  Thanks.

    understand the deflate format?

    contrib/puff directory.

    zlib.  Look here for some more information:

    Each call of inflate() or deflate() is limited to input and output chunks

    of the maximum value that can be stored in the compiler's "unsigned int"

    type, but there is no limit to the number of chunks.  Note however that the

    strm.total_in and strm_total_out counters may be limited to 4 GB.  These

    counters are provided as a convenience and are not used internally by

    inflate() or deflate().  The application can easily set up its own counters

    updated after each call of inflate() or deflate() to count beyond 4 GB.

    compress() and uncompress() may be limited to 4 GB, since they operate in a

    single call.  gzseek() and gztell() may be limited to 4 GB depending on how

    zlib is compiled.  See the zlibCompileFlags() function in zlib.h.

    if the compiler's "long" type is 32 bits.  If the compiler's "long" type is

    64 bits, then the limit is 16 exabytes.

    compiled to use sprintf() or vsprintf(), then there is no protection

    against a buffer overflow of an 8K string space (or other value as set by

    gzbuffer()), other than the caller of gzprintf() assuring that the output

    will not exceed 8K.  On the other hand, if zlib is compiled to use

    snprintf() or vsnprintf(), which should normally be the case, then there is

    no vulnerability.  The ./configure script will display warnings if an

    insecure variation of sprintf() will be used by gzprintf().  Also the

    zlibCompileFlags() function will return information on what variant of

    sprintf() is used by gzprintf().

    find a portable implementation here:

    1.1.3 and before were subject to a double-free vulnerability, and versions

    1.2.1 and 1.2.2 were subject to an access exception when decompressing

    invalid compressed data.

    as part of the Java SDK in the java.util.zip package. If you really want

    a version of zlib written in the Java language, look on the zlib home

    page for links: http://zlib.net/ .

    up to maximally-pedantic. Can't you guys write proper code?

    in the universe.  It just got to be a waste of time, and some compilers

    were downright silly as well as contradicted each other.  So now, we simply

    make sure that the code always works.

    performing a conditional jump that depends on an uninitialized value.

    Isn't that a bug?

    is not affected.  This only started showing up recently since zlib 1.2.x

    uses malloc() by default for allocations, whereas earlier versions used

    calloc(), which zeros out the allocated memory.  Even though the code was

    correct, versions 1.2.4 and later was changed to not stimulate these

    checkers.

    data format?

    formats and associated software.

    weak and can be broken with freely available programs.  To get strong

    encryption, use GnuPG, http://www.gnupg.org/ , which already includes zlib

    compression.  For PKZIP compatible "encryption", look at

    http://www.info-zip.org/

    probably have called the second one "zlib" instead to avoid confusion with

    the raw deflate compressed data format.  While the HTTP 1.1 RFC 2616

    correctly points to the zlib specification in RFC 1950 for the "deflate"

    transfer encoding, there have been reports of servers and browsers that

    incorrectly produce or expect raw deflate data per the deflate

    specification in RFC 1951, most notably Microsoft.  So even though the

    "deflate" transfer encoding using the zlib format would be the more

    efficient approach (and in fact exactly what the zlib format was designed

    for), using the "gzip" transfer encoding is probably more reliable due to

    an unfortunate choice of name on the part of the HTTP 1.1 authors.

    they have not documented it as they have previous compression formats.  In

    any case, the compression improvements are so modest compared to other more

    modern approaches, that it's not worth the effort to implement.

    Giles Vollant, which is found in the contrib directory of zlib.  It is not

    part of zlib.  In fact none of the stuff in contrib is part of zlib.  The

    files in there are not supported by the zlib authors.  You need to contact

    the authors of the respective contribution for help.

    Since it's part of zlib, doesn't that mean that all of zlib falls under the

    GNU GPL?

    other authors and are provided as a convenience to the user within the zlib

    distribution.  Each item in contrib has its own license.

    so that we can use your software in our product?