< draft-deutsch-zlib-spec-01.txt   draft-deutsch-zlib-spec-02.txt >
INTERNET-DRAFT L. Peter Deutsch INTERNET-DRAFT L. Peter Deutsch
ZLIB 3.3 Aladdin Enterprises ZLIB 3.3 Aladdin Enterprises
Expires: 17 Aug 1996 Jean-Loup Gailly Expires: 16 Sep 1996 Jean-Loup Gailly
Info-Zip Info-Zip
12 Feb 1996 11 Mar 1996
ZLIB Compressed Data Format Specification version 3.3 ZLIB Compressed Data Format Specification version 3.3
File draft-deutsch-zlib-spec-01.txt File draft-deutsch-zlib-spec-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 32 skipping to change at line 32
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts ``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Notices Notices
Copyright (C) 1996 L. Peter Deutsch and Jean-loup Gailly Copyright (c) 1996 L. Peter Deutsch and Jean-loup Gailly
Permission is granted to copy and distribute this document for any Permission is granted to copy and distribute this document for any
purpose and without charge, including translations into other purpose and without charge, including translations into other
languages and incorporation into compilations, provided that it is languages and incorporation into compilations, provided that it is
copied as a whole (including the copyright notice and this notice) copied as a whole (including the copyright notice and this notice)
and with no changes. and with no changes.
Deutsch and Gailly [Page 1]
Abstract Abstract
This specification defines a lossless compressed data format. The This specification defines a lossless compressed data format. The
data can be produced or consumed, even for an arbitrarily long data can be produced or consumed, even for an arbitrarily long
sequentially presented input data stream, using only an a priori sequentially presented input data stream, using only an a priori
bounded amount of intermediate storage. The format presently uses bounded amount of intermediate storage. The format presently uses
the DEFLATE compression method but can be easily extended to use the DEFLATE compression method but can be easily extended to use
other compression methods. It can be implemented readily in a manner other compression methods. It can be implemented readily in a manner
Deutsch and Gailly [Page 1]
not covered by patents. This specification also defines the ADLER-32 not covered by patents. This specification also defines the ADLER-32
checksum (an extension and improvement of the Fletcher checksum), checksum (an extension and improvement of the Fletcher checksum),
used for detection of data corruption, and provides an algorithm for used for detection of data corruption, and provides an algorithm for
computing it. computing it.
Table of contents Table of Contents
1. Introduction ................................................... 2 1. Introduction ................................................... 2
1.1 Purpose .................................................... 2 1.1. Purpose ................................................... 2
1.2 Intended audience .......................................... 2 1.2. Intended audience ......................................... 3
1.3 Scope ...................................................... 3 1.3. Scope ..................................................... 3
1.4 Compliance ................................................. 3 1.4. Compliance ................................................ 3
1.5 Definitions of terms and conventions used ................. 3 1.5. Definitions of terms and conventions used ................ 3
1.6 Changes from previous versions ............................. 3 1.6. Changes from previous versions ............................ 3
2. Detailed specification ......................................... 3 2. Detailed specification ......................................... 4
2.1 Overall conventions ........................................ 3 2.1. Overall conventions ....................................... 4
2.2 Data format ................................................ 4 2.2. Data format ............................................... 4
2.3 Compliance ................................................. 6 2.3. Compliance ................................................ 6
3. References ..................................................... 7 3. References ..................................................... 7
4. Source code .................................................... 7 4. Source code .................................................... 7
5. Security considerations ........................................ 7 5. Security considerations ........................................ 8
6. Acknowledgements ............................................... 7 6. Acknowledgements ............................................... 8
7. Authors' addresses ............................................. 7 7. Authors' addresses ............................................. 8
8. Appendix: Rationale ............................................ 8 8. Appendix: Rationale ............................................ 8
9. Appendix: Sample code .......................................... 9 9. Appendix: Sample code .......................................... 9
1. Introduction 1. Introduction
1.1. Purpose 1.1. Purpose
The purpose of this specification is to define a lossless The purpose of this specification is to define a lossless
compressed data format that: compressed data format that:
o Is independent of CPU type, operating system, file system, * Is independent of CPU type, operating system, file system,
and character set, and hence can be used for interchange; and character set, and hence can be used for interchange;
o Can be produced or consumed, even for an arbitrarily long * Can be produced or consumed, even for an arbitrarily long
sequentially presented input data stream, using only an a sequentially presented input data stream, using only an a
priori bounded amount of intermediate storage, and hence can priori bounded amount of intermediate storage, and hence can
be used in data communications or similar structures such as be used in data communications or similar structures such as
Unix filters; Unix filters;
* Can use a number of different compression methods;
o Can use a number of different compression methods; * Can be implemented readily in a manner not covered by
o Can be implemented readily in a manner not covered by Deutsch and Gailly [Page 2]
patents, and hence can be practiced freely. patents, and hence can be practiced freely.
The data format defined by this specification does not attempt to The data format defined by this specification does not attempt to
allow random access to compressed data. allow random access to compressed data.
1.2. Intended audience 1.2. Intended audience
This specification is intended for use by implementors of software This specification is intended for use by implementors of software
Deutsch and Gailly [Page 2]
to compress data into zlib format and/or decompress data from zlib to compress data into zlib format and/or decompress data from zlib
format. format.
The text of the specification assumes a basic background in The text of the specification assumes a basic background in
programming at the level of bits and other primitive data programming at the level of bits and other primitive data
representations. representations.
1.3. Scope 1.3. Scope
The specification specifies a compressed data format that can be The specification specifies a compressed data format that can be
skipping to change at line 131 skipping to change at line 130
able to accept and decompress any data set that conforms to all able to accept and decompress any data set that conforms to all
the specifications presented here; a compliant compressor must the specifications presented here; a compliant compressor must
produce data sets that conform to all the specifications presented produce data sets that conform to all the specifications presented
here. here.
1.5. Definitions of terms and conventions used 1.5. Definitions of terms and conventions used
byte: 8 bits stored or transmitted as a unit (same as an octet). byte: 8 bits stored or transmitted as a unit (same as an octet).
(For this specification, a byte is exactly 8 bits, even on (For this specification, a byte is exactly 8 bits, even on
machines which store a character on a number of bits different machines which store a character on a number of bits different
from 8.) See Section 2.1, below, for the numbering of bits within from 8.) See below, for the numbering of bits within a byte.
a byte.
1.6. Changes from previous versions 1.6. Changes from previous versions
Version 3.1 was the first public release of this specification. Version 3.1 was the first public release of this specification.
In version 3.2, some terminology was changed and the Adler-32 In version 3.2, some terminology was changed and the Adler-32
sample code was rewritten for clarity. In version 3.3, the sample code was rewritten for clarity. In version 3.3, the
support for a preset dictionary was introduced, and the support for a preset dictionary was introduced, and the
specification was converted to Internet Draft style. specification was converted to Internet Draft style.
Deutsch and Gailly [Page 3]
2. Detailed specification 2. Detailed specification
2.1. Overall conventions 2.1. Overall conventions
In the diagrams below, a box like this: In the diagrams below, a box like this:
+---+ +---+
| | <-- the vertical bars might be missing | | <-- the vertical bars might be missing
+---+ +---+
represents one byte; a box like this: represents one byte; a box like this:
+==============+ +==============+
| | | |
+==============+ +==============+
Deutsch and Gailly [Page 3]
represents a variable number of bytes. represents a variable number of bytes.
Bytes stored within a computer do not have a 'bit order', since Bytes stored within a computer do not have a 'bit order', since
they are always treated as a unit. However, a byte considered as they are always treated as a unit. However, a byte considered as
an integer between 0 and 255 does have a most- and least- an integer between 0 and 255 does have a most- and least-
significant bit, and since we write numbers with the most- significant bit, and since we write numbers with the most-
significant digit on the left, we also write bytes with the most- significant digit on the left, we also write bytes with the most-
significant bit on the left. In the diagrams below, we number the significant bit on the left. In the diagrams below, we number the
bits of a byte so that bit 0 is the least-significant bit, i.e., bits of a byte so that bit 0 is the least-significant bit, i.e.,
the bits are numbered: the bits are numbered:
skipping to change at line 192 skipping to change at line 190
+--------+--------+ +--------+--------+
^ ^ ^ ^
| | | |
| + less significant byte = 8 | + less significant byte = 8
+ more significant byte = 2 x 256 + more significant byte = 2 x 256
2.2. Data format 2.2. Data format
A zlib stream has the following structure: A zlib stream has the following structure:
Deutsch and Gailly [Page 4]
0 1 0 1
+---+---+ +---+---+
|CMF|FLG| (more-->) |CMF|FLG| (more-->)
+---+---+ +---+---+
(if FLG.FDICT set) (if FLG.FDICT set)
0 1 2 3 0 1 2 3
+---+---+---+---+ +---+---+---+---+
| DICTID | (more-->) | DICTID | (more-->)
+---+---+---+---+ +---+---+---+---+
+=====================+---+---+---+---+ +=====================+---+---+---+---+
|...compressed data...| ADLER32 | |...compressed data...| ADLER32 |
+=====================+---+---+---+---+ +=====================+---+---+---+---+
Any data which may appear after ADLER32 are not part of the zlib Any data which may appear after ADLER32 are not part of the zlib
stream. stream.
Deutsch and Gailly [Page 4]
CMF (Compression Method and flags) CMF (Compression Method and flags)
This byte is divided into a 4-bit compression method and a 4- This byte is divided into a 4-bit compression method and a 4-
bit information field depending on the compression method. bit information field depending on the compression method.
bits 0 to 3 CM Compression method bits 0 to 3 CM Compression method
bits 4 to 7 CINFO Compression info bits 4 to 7 CINFO Compression info
CM (Compression method) CM (Compression method)
This identifies the compression method used in the file. CM = 8 This identifies the compression method used in the file. CM = 8
denotes the 'deflate' compression method with a window size up denotes the 'deflate' compression method with a window size up
to 32K. This is the method used by gzip and PNG (see to 32K. This is the method used by gzip and PNG (see
references [1] and [2] in Chapter 3, below, for the reference references [1] and [2] in Chapter 3, below, for the reference
documents). CM = 15 is reserved. It might be used in a future documents). CM = 15 is reserved. It might be used in a future
version of this specification to indicate the presence of an version of this specification to indicate the presence of an
extra field before the compressed data. extra field before the compressed data.
CINFO (Compression info) CINFO (Compression info)
For CM = 8, CINFO is the base-2 logarithm of the LZ77 window For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
size, minus eight (CINFO=7 indicates a 32K window size). Values size, minus eight (CINFO=7 indicates a 32K window size). Values
of CINFO above 7 are not allowed in this version of the of CINFO above 7 are not allowed in this version of the
specification. CINFO is not defined in this specification for specification. CINFO is not defined in this specification for
CM not equal to 8. CM not equal to 8.
FLG (FLaGs) FLG (FLaGs)
This flag byte is divided as follows: This flag byte is divided as follows:
bits 0 to 4 FCHECK (check bits for CMF and FLG) bits 0 to 4 FCHECK (check bits for CMF and FLG)
bit 5 FDICT (preset dictionary) bit 5 FDICT (preset dictionary)
bits 6 to 7 FLEVEL (compression level) bits 6 to 7 FLEVEL (compression level)
The FCHECK value must be such that CMF and FLG, when viewed as The FCHECK value must be such that CMF and FLG, when viewed as
a 16-bit unsigned integer stored in MSB order (CMF*256 + FLG), a 16-bit unsigned integer stored in MSB order (CMF*256 + FLG),
is a multiple of 31. is a multiple of 31.
Deutsch and Gailly [Page 5]
FDICT (Preset dictionary) FDICT (Preset dictionary)
If FDICT is set, a DICT dictionary identifier is present If FDICT is set, a DICT dictionary identifier is present
immediately after the FLG byte. The dictionary is a sequence of immediately after the FLG byte. The dictionary is a sequence of
bytes which are initially fed to the compressor without bytes which are initially fed to the compressor without
producing any compressed output. DICT is the Adler-32 checksum producing any compressed output. DICT is the Adler-32 checksum
of this sequence of bytes (see the definition of ADLER32 of this sequence of bytes (see the definition of ADLER32
below). The decompressor can use this identifier to determine below). The decompressor can use this identifier to determine
which dictionary has been used by the compressor. which dictionary has been used by the compressor.
FLEVEL (Compression level) FLEVEL (Compression level)
These flags are available for use by specific compression These flags are available for use by specific compression
methods. The 'deflate' method (CM = 8) sets these flags as methods. The 'deflate' method (CM = 8) sets these flags as
Deutsch and Gailly [Page 5]
follows: follows:
0 - compressor used fastest algorithm 0 - compressor used fastest algorithm
1 - compressor used fast algorithm 1 - compressor used fast algorithm
2 - compressor used default algorithm 2 - compressor used default algorithm
3 - compressor used maximum compression, slowest algorithm 3 - compressor used maximum compression, slowest algorithm
The information in FLEVEL is not needed for decompression; it The information in FLEVEL is not needed for decompression; it
is there to indicate if recompression might be worthwhile. is there to indicate if recompression might be worthwhile.
skipping to change at line 277 skipping to change at line 268
0 - compressor used fastest algorithm 0 - compressor used fastest algorithm
1 - compressor used fast algorithm 1 - compressor used fast algorithm
2 - compressor used default algorithm 2 - compressor used default algorithm
3 - compressor used maximum compression, slowest algorithm 3 - compressor used maximum compression, slowest algorithm
The information in FLEVEL is not needed for decompression; it The information in FLEVEL is not needed for decompression; it
is there to indicate if recompression might be worthwhile. is there to indicate if recompression might be worthwhile.
compressed data compressed data
For compression method 8, the compressed data is stored in the For compression method 8, the compressed data is stored in the
deflate compressed data format as described in the document deflate compressed data format as described in the document
"'Deflate' Compressed Data Format Specification" by L. Peter "'Deflate' Compressed Data Format Specification" by L. Peter
Deutsch. (See reference [3] in Chapter 3, below) Deutsch. (See reference [3] in Chapter 3, below)
Other compressed data formats are not specified in this version Other compressed data formats are not specified in this version
of the zlib specification. of the zlib specification.
ADLER32 (Adler-32 checksum) ADLER32 (Adler-32 checksum)
This contains a checksum value of the uncompressed data This contains a checksum value of the uncompressed data
(excluding any dictionary data) computed according to Adler-32 (excluding any dictionary data) computed according to Adler-32
algorithm. This algorithm is a 32-bit extension and improvement algorithm. This algorithm is a 32-bit extension and improvement
of the Fletcher algorithm, used in the ITU-T X.224 / ISO 8073 of the Fletcher algorithm, used in the ITU-T X.224 / ISO 8073
standard. See references [4] and [5] in Chapter 3, below) standard. See references [4] and [5] in Chapter 3, below)
Adler-32 is composed of two sums accumulated per byte: s1 is Adler-32 is composed of two sums accumulated per byte: s1 is
the sum of all bytes, s2 is the sum of all s1 values. Both sums the sum of all bytes, s2 is the sum of all s1 values. Both sums
are done modulo 65521. s1 is initialized to 1, s2 to zero. The are done modulo 65521. s1 is initialized to 1, s2 to zero. The
Adler-32 checksum is stored as s2*65536 + s1 in most- Adler-32 checksum is stored as s2*65536 + s1 in most-
significant-byte first (network) order. significant-byte first (network) order.
2.3. Compliance 2.3. Compliance
A compliant compressor must produce streams with correct CMF, FLG A compliant compressor must produce streams with correct CMF, FLG
and ADLER32, but need not support preset dictionaries. When the and ADLER32, but need not support preset dictionaries. When the
zlib data format is used as part of another standard data format, zlib data format is used as part of another standard data format,
the compressor may use only preset dictionaries that are specified the compressor may use only preset dictionaries that are specified
by this other data format. If this other format does not use the by this other data format. If this other format does not use the
preset dictionary feature, the compressor must not set the FDICT preset dictionary feature, the compressor must not set the FDICT
Deutsch and Gailly [Page 6]
flag. flag.
A compliant decompressor must check CMF, FLG, and ADLER32, and A compliant decompressor must check CMF, FLG, and ADLER32, and
provide an error indication if any of these have incorrect values. provide an error indication if any of these have incorrect values.
A compliant decompressor must give an error indication if CM is A compliant decompressor must give an error indication if CM is
not one of the values defined in this specification (only the not one of the values defined in this specification (only the
value 8 is permitted in this version), since another value could value 8 is permitted in this version), since another value could
indicate the presence of new features that would cause subsequent indicate the presence of new features that would cause subsequent
data to be interpreted incorrectly. A compliant decompressor must data to be interpreted incorrectly. A compliant decompressor must
give an error indication if FDICT is set and DICTID is not the give an error indication if FDICT is set and DICTID is not the
Deutsch and Gailly [Page 6]
identifier of a known preset dictionary. A decompressor may identifier of a known preset dictionary. A decompressor may
ignore FLEVEL and still be compliant. When the zlib data format ignore FLEVEL and still be compliant. When the zlib data format
is being used as a part of another standard format, a compliant is being used as a part of another standard format, a compliant
decompressor must support all the preset dictionaries specified by decompressor must support all the preset dictionaries specified by
the other format. When the other format does not use the preset the other format. When the other format does not use the preset
dictionary feature, a compliant decompressor must reject any dictionary feature, a compliant decompressor must reject any
stream in which the FDICT flag is set. stream in which the FDICT flag is set.
3. References 3. References
[1] Deutsch, L.P.,"'Gzip' Compressed Data Format Specification". [1] Deutsch, L.P.,"'Gzip' Compressed Data Format Specification".
available in ftp.uu.net:/pub/archiving/zip/doc/gzip-*.doc available in ftp.uu.net:/pub/archiving/zip/doc/gzip-*.doc
[2] Thomas Boutell, "PNG (Portable Network Graphics) specification". [2] Thomas Boutell, "PNG (Portable Network Graphics) specification".
available in ftp://ftp.uu.net/graphics/png/png* available in ftp://ftp.uu.net/graphics/png/png*
[3] Deutsch, L.P.,"'Deflate' Compressed Data Format Specification". [3] Deutsch, L.P.,"'Deflate' Compressed Data Format Specification".
available in ftp.uu.net:/pub/archiving/zip/doc/deflate-*.doc available in ftp.uu.net:/pub/archiving/zip/doc/deflate-*.doc
[4] Fletcher, J. G., "An Arithmetic Checksum for Serial [4] Fletcher, J. G., "An Arithmetic Checksum for Serial
Transmissions," IEEE Transactions on Communications, Vol. COM-30, No. Transmissions," IEEE Transactions on Communications, Vol. COM-30,
1, January 1982, pp. 247-252. No. 1, January 1982, pp. 247-252.
[5] ITU-T Recommendation X.224, Annex D, "Checksum Algorithms," [5] ITU-T Recommendation X.224, Annex D, "Checksum Algorithms,"
November, 1993, pp. 144, 145. (Available from gopher://info.itu.ch). November, 1993, pp. 144, 145. (Available from
ITU-T X.244 is also the same as ISO 8073. gopher://info.itu.ch). ITU-T X.244 is also the same as ISO 8073.
4. Source code 4. Source code
Source code for a C language implementation of a 'zlib' compliant Source code for a C language implementation of a 'zlib' compliant
library is available at ftp.uu.net:/pub/archiving/zip/zlib/zlib*. library is available at ftp.uu.net:/pub/archiving/zip/zlib/zlib*.
Deutsch and Gailly [Page 7]
5. Security considerations 5. Security considerations
A decoder that fails to check the ADLER32 checksum value may be A decoder that fails to check the ADLER32 checksum value may be
subject to undetected data corruption. subject to undetected data corruption.
6. Acknowledgements 6. Acknowledgements
Trademarks cited in this document are the property of their Trademarks cited in this document are the property of their
respective owners. respective owners.
skipping to change at line 373 skipping to change at line 363
the related software described in this specification. Glenn the related software described in this specification. Glenn
Randers-Pehrson converted this document to Internet Draft and HTML Randers-Pehrson converted this document to Internet Draft and HTML
format. format.
7. Authors' addresses L. Peter Deutsch 7. Authors' addresses L. Peter Deutsch
Aladdin Enterprises Aladdin Enterprises
203 Santa Margarita Ave. 203 Santa Margarita Ave.
Menlo Park, CA 94025 Menlo Park, CA 94025
Deutsch and Gailly [Page 7]
Phone: (415) 322-0103 (AM only) Phone: (415) 322-0103 (AM only)
FAX: (415) 322-1734 FAX: (415) 322-1734
EMail: <ghost@aladdin.com> EMail: <ghost@aladdin.com>
Jean-loup Gailly Jean-loup Gailly
EMail: <gzip@prep.ai.mit.edu> EMail: <gzip@prep.ai.mit.edu>
Questions about the technical content of this specification can be Questions about the technical content of this specification can be
sent by email to sent by email to
skipping to change at line 403 skipping to change at line 392
8. Appendix: Rationale 8. Appendix: Rationale
8.1. Preset dictionaries 8.1. Preset dictionaries
A preset dictionary is specially useful to compress short input A preset dictionary is specially useful to compress short input
sequences. The compressor can take advantage of the dictionary sequences. The compressor can take advantage of the dictionary
context to encode the input in a more compact manner. The context to encode the input in a more compact manner. The
decompressor can be initialized with the appropriate context by decompressor can be initialized with the appropriate context by
virtually decompressing a compressed version of the dictionary virtually decompressing a compressed version of the dictionary
without producing any output. However for certain compression without producing any output. However for certain compression
algorithms such as the deflate algorithm this operation be algorithms such as the deflate algorithm this operation can be
optimized without actually performing any decompression. achieved without actually performing any decompression.
Deutsch and Gailly [Page 8]
The compressor and the decompressor must use exactly the same The compressor and the decompressor must use exactly the same
dictionary. The dictionary may be fixed or may be chosen among a dictionary. The dictionary may be fixed or may be chosen among a
certain number of predefined dictionaries, according to the kind certain number of predefined dictionaries, according to the kind
of input data. The decompressor can determine which dictionary has of input data. The decompressor can determine which dictionary has
been chosen by the compressor by checking the dictionary been chosen by the compressor by checking the dictionary
identifier. This document does not specify the contents of identifier. This document does not specify the contents of
predefined dictionaries, since the optimal dictionaries are predefined dictionaries, since the optimal dictionaries are
application specific. Standard data formats using this feature of application specific. Standard data formats using this feature of
the zlib specification must precisely define the allowed the zlib specification must precisely define the allowed
dictionaries. dictionaries.
8.2. The Adler-32 algorithm 8.2. The Adler-32 algorithm
The Adler-32 algorithm is much faster than the CRC32 algorithm yet The Adler-32 algorithm is much faster than the CRC32 algorithm yet
still provides an extremely low probability of undetected errors. still provides an extremely low probability of undetected errors.
The modulo on unsigned long accumulators can be delayed for 5552 The modulo on unsigned long accumulators can be delayed for 5552
bytes, so the modulo operation time is negligible. If the bytes bytes, so the modulo operation time is negligible. If the bytes
are a, b, c, the second sum is 3a + 2b + c + 3, and so is position are a, b, c, the second sum is 3a + 2b + c + 3, and so is position
and order sensitive, unlike the first sum, which is just a and order sensitive, unlike the first sum, which is just a
Deutsch and Gailly [Page 8]
checksum. That 65521 is prime is important to avoid a possible checksum. That 65521 is prime is important to avoid a possible
large class of two-byte errors that leave the check unchanged. large class of two-byte errors that leave the check unchanged.
(The Fletcher checksum uses 255, which is not prime and which also (The Fletcher checksum uses 255, which is not prime and which also
makes the Fletcher check insensitive to single byte changes 0 makes the Fletcher check insensitive to single byte changes 0
255.) 255.)
The sum s1 is initialized to 1 instead of zero to make the length The sum s1 is initialized to 1 instead of zero to make the length
of the sequence part of s2, so that the length does not have to be of the sequence part of s2, so that the length does not have to be
checked separately. (Any sequence of zeroes has a Fletcher checked separately. (Any sequence of zeroes has a Fletcher
checksum of zero.) checksum of zero.)
skipping to change at line 457 skipping to change at line 445
>> Bitwise right shift operator. When applied to an >> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s) unsigned quantity, as here, right shift inserts zero bit(s)
at the left. at the left.
<< Bitwise left shift operator. Left shift inserts zero << Bitwise left shift operator. Left shift inserts zero
bit(s) at the right. bit(s) at the right.
++ "n++" increments the variable n. ++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b. % modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */ #define BASE 65521 /* largest prime smaller than 65536 */
Deutsch and Gailly [Page 9]
/* /*
Update a running Adler-32 checksum with the bytes buf[0..len-1] Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should be and return the updated checksum. The Adler-32 checksum should be
initialized to 1. initialized to 1.
Usage example: Usage example:
unsigned long adler = 1L; unsigned long adler = 1L;
while (read_buffer(buffer, length) != EOF) { while (read_buffer(buffer, length) != EOF) {
skipping to change at line 480 skipping to change at line 469
*/ */
unsigned long update_adler32(unsigned long adler, unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len) unsigned char *buf, int len)
{ {
unsigned long s1 = adler & 0xffff; unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff; unsigned long s2 = (adler >> 16) & 0xffff;
int n; int n;
for (n = 0; n < len; n++) { for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE; s1 = (s1 + buf[n]) % BASE;
Deutsch and Gailly [Page 9]
s2 = (s2 + s1) % BASE; s2 = (s2 + s1) % BASE;
} }
return (s2 << 16) + s1; return (s2 << 16) + s1;
} }
/* Return the adler32 of the bytes buf[0..len-1] */ /* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len) unsigned long adler32(unsigned char *buf, int len)
{ {
return update_adler32(1L, buf, len); return update_adler32(1L, buf, len);
 End of changes. 46 change blocks. 
57 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/