Mercurial > hg > sv-dependency-builds

annotate src/zlib-1.2.7/doc/rfc1950.txt @ 169:223a55898ab9 tip default

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Add null config files
author Chris Cannam <cannam@all-day-breakfast.com>
date Mon, 02 Mar 2020 14:03:47 +0000
parents 8a15ff55d9af
children
rev   line source
cannam@89 1
cannam@89 2
cannam@89 3
cannam@89 4
cannam@89 5
cannam@89 6
cannam@89 7 Network Working Group P. Deutsch
cannam@89 8 Request for Comments: 1950 Aladdin Enterprises
cannam@89 9 Category: Informational J-L. Gailly
cannam@89 10 Info-ZIP
cannam@89 11 May 1996
cannam@89 12
cannam@89 13
cannam@89 14 ZLIB Compressed Data Format Specification version 3.3
cannam@89 15
cannam@89 16 Status of This Memo
cannam@89 17
cannam@89 18 This memo provides information for the Internet community. This memo
cannam@89 19 does not specify an Internet standard of any kind. Distribution of
cannam@89 20 this memo is unlimited.
cannam@89 21
cannam@89 22 IESG Note:
cannam@89 23
cannam@89 24 The IESG takes no position on the validity of any Intellectual
cannam@89 25 Property Rights statements contained in this document.
cannam@89 26
cannam@89 27 Notices
cannam@89 28
cannam@89 29 Copyright (c) 1996 L. Peter Deutsch and Jean-Loup Gailly
cannam@89 30
cannam@89 31 Permission is granted to copy and distribute this document for any
cannam@89 32 purpose and without charge, including translations into other
cannam@89 33 languages and incorporation into compilations, provided that the
cannam@89 34 copyright notice and this notice are preserved, and that any
cannam@89 35 substantive changes or deletions from the original are clearly
cannam@89 36 marked.
cannam@89 37
cannam@89 38 A pointer to the latest version of this and related documentation in
cannam@89 39 HTML format can be found at the URL
cannam@89 40 <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>.
cannam@89 41
cannam@89 42 Abstract
cannam@89 43
cannam@89 44 This specification defines a lossless compressed data format. The
cannam@89 45 data can be produced or consumed, even for an arbitrarily long
cannam@89 46 sequentially presented input data stream, using only an a priori
cannam@89 47 bounded amount of intermediate storage. The format presently uses
cannam@89 48 the DEFLATE compression method but can be easily extended to use
cannam@89 49 other compression methods. It can be implemented readily in a manner
cannam@89 50 not covered by patents. This specification also defines the ADLER-32
cannam@89 51 checksum (an extension and improvement of the Fletcher checksum),
cannam@89 52 used for detection of data corruption, and provides an algorithm for
cannam@89 53 computing it.
cannam@89 54
cannam@89 55
cannam@89 56
cannam@89 57
cannam@89 58 Deutsch & Gailly Informational [Page 1]
cannam@89 59
cannam@89 60 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 61
cannam@89 62
cannam@89 63 Table of Contents
cannam@89 64
cannam@89 65 1. Introduction ................................................... 2
cannam@89 66 1.1. Purpose ................................................... 2
cannam@89 67 1.2. Intended audience ......................................... 3
cannam@89 68 1.3. Scope ..................................................... 3
cannam@89 69 1.4. Compliance ................................................ 3
cannam@89 70 1.5. Definitions of terms and conventions used ................ 3
cannam@89 71 1.6. Changes from previous versions ............................ 3
cannam@89 72 2. Detailed specification ......................................... 3
cannam@89 73 2.1. Overall conventions ....................................... 3
cannam@89 74 2.2. Data format ............................................... 4
cannam@89 75 2.3. Compliance ................................................ 7
cannam@89 76 3. References ..................................................... 7
cannam@89 77 4. Source code .................................................... 8
cannam@89 78 5. Security Considerations ........................................ 8
cannam@89 79 6. Acknowledgements ............................................... 8
cannam@89 80 7. Authors' Addresses ............................................. 8
cannam@89 81 8. Appendix: Rationale ............................................ 9
cannam@89 82 9. Appendix: Sample code ..........................................10
cannam@89 83
cannam@89 84 1. Introduction
cannam@89 85
cannam@89 86 1.1. Purpose
cannam@89 87
cannam@89 88 The purpose of this specification is to define a lossless
cannam@89 89 compressed data format that:
cannam@89 90
cannam@89 91 * Is independent of CPU type, operating system, file system,
cannam@89 92 and character set, and hence can be used for interchange;
cannam@89 93
cannam@89 94 * Can be produced or consumed, even for an arbitrarily long
cannam@89 95 sequentially presented input data stream, using only an a
cannam@89 96 priori bounded amount of intermediate storage, and hence can
cannam@89 97 be used in data communications or similar structures such as
cannam@89 98 Unix filters;
cannam@89 99
cannam@89 100 * Can use a number of different compression methods;
cannam@89 101
cannam@89 102 * Can be implemented readily in a manner not covered by
cannam@89 103 patents, and hence can be practiced freely.
cannam@89 104
cannam@89 105 The data format defined by this specification does not attempt to
cannam@89 106 allow random access to compressed data.
cannam@89 107
cannam@89 108
cannam@89 109
cannam@89 110
cannam@89 111
cannam@89 112
cannam@89 113
cannam@89 114 Deutsch & Gailly Informational [Page 2]
cannam@89 115
cannam@89 116 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 117
cannam@89 118
cannam@89 119 1.2. Intended audience
cannam@89 120
cannam@89 121 This specification is intended for use by implementors of software
cannam@89 122 to compress data into zlib format and/or decompress data from zlib
cannam@89 123 format.
cannam@89 124
cannam@89 125 The text of the specification assumes a basic background in
cannam@89 126 programming at the level of bits and other primitive data
cannam@89 127 representations.
cannam@89 128
cannam@89 129 1.3. Scope
cannam@89 130
cannam@89 131 The specification specifies a compressed data format that can be
cannam@89 132 used for in-memory compression of a sequence of arbitrary bytes.
cannam@89 133
cannam@89 134 1.4. Compliance
cannam@89 135
cannam@89 136 Unless otherwise indicated below, a compliant decompressor must be
cannam@89 137 able to accept and decompress any data set that conforms to all
cannam@89 138 the specifications presented here; a compliant compressor must
cannam@89 139 produce data sets that conform to all the specifications presented
cannam@89 140 here.
cannam@89 141
cannam@89 142 1.5. Definitions of terms and conventions used
cannam@89 143
cannam@89 144 byte: 8 bits stored or transmitted as a unit (same as an octet).
cannam@89 145 (For this specification, a byte is exactly 8 bits, even on
cannam@89 146 machines which store a character on a number of bits different
cannam@89 147 from 8.) See below, for the numbering of bits within a byte.
cannam@89 148
cannam@89 149 1.6. Changes from previous versions
cannam@89 150
cannam@89 151 Version 3.1 was the first public release of this specification.
cannam@89 152 In version 3.2, some terminology was changed and the Adler-32
cannam@89 153 sample code was rewritten for clarity. In version 3.3, the
cannam@89 154 support for a preset dictionary was introduced, and the
cannam@89 155 specification was converted to RFC style.
cannam@89 156
cannam@89 157 2. Detailed specification
cannam@89 158
cannam@89 159 2.1. Overall conventions
cannam@89 160
cannam@89 161 In the diagrams below, a box like this:
cannam@89 162
cannam@89 163 +---+
cannam@89 164 | | <-- the vertical bars might be missing
cannam@89 165 +---+
cannam@89 166
cannam@89 167
cannam@89 168
cannam@89 169
cannam@89 170 Deutsch & Gailly Informational [Page 3]
cannam@89 171
cannam@89 172 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 173
cannam@89 174
cannam@89 175 represents one byte; a box like this:
cannam@89 176
cannam@89 177 +==============+
cannam@89 178 | |
cannam@89 179 +==============+
cannam@89 180
cannam@89 181 represents a variable number of bytes.
cannam@89 182
cannam@89 183 Bytes stored within a computer do not have a "bit order", since
cannam@89 184 they are always treated as a unit. However, a byte considered as
cannam@89 185 an integer between 0 and 255 does have a most- and least-
cannam@89 186 significant bit, and since we write numbers with the most-
cannam@89 187 significant digit on the left, we also write bytes with the most-
cannam@89 188 significant bit on the left. In the diagrams below, we number the
cannam@89 189 bits of a byte so that bit 0 is the least-significant bit, i.e.,
cannam@89 190 the bits are numbered:
cannam@89 191
cannam@89 192 +--------+
cannam@89 193 |76543210|
cannam@89 194 +--------+
cannam@89 195
cannam@89 196 Within a computer, a number may occupy multiple bytes. All
cannam@89 197 multi-byte numbers in the format described here are stored with
cannam@89 198 the MOST-significant byte first (at the lower memory address).
cannam@89 199 For example, the decimal number 520 is stored as:
cannam@89 200
cannam@89 201 0 1
cannam@89 202 +--------+--------+
cannam@89 203 |00000010|00001000|
cannam@89 204 +--------+--------+
cannam@89 205 ^ ^
cannam@89 206 | |
cannam@89 207 | + less significant byte = 8
cannam@89 208 + more significant byte = 2 x 256
cannam@89 209
cannam@89 210 2.2. Data format
cannam@89 211
cannam@89 212 A zlib stream has the following structure:
cannam@89 213
cannam@89 214 0 1
cannam@89 215 +---+---+
cannam@89 216 |CMF|FLG| (more-->)
cannam@89 217 +---+---+
cannam@89 218
cannam@89 219
cannam@89 220
cannam@89 221
cannam@89 222
cannam@89 223
cannam@89 224
cannam@89 225
cannam@89 226 Deutsch & Gailly Informational [Page 4]
cannam@89 227
cannam@89 228 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 229
cannam@89 230
cannam@89 231 (if FLG.FDICT set)
cannam@89 232
cannam@89 233 0 1 2 3
cannam@89 234 +---+---+---+---+
cannam@89 235 | DICTID | (more-->)
cannam@89 236 +---+---+---+---+
cannam@89 237
cannam@89 238 +=====================+---+---+---+---+
cannam@89 239 |...compressed data...| ADLER32 |
cannam@89 240 +=====================+---+---+---+---+
cannam@89 241
cannam@89 242 Any data which may appear after ADLER32 are not part of the zlib
cannam@89 243 stream.
cannam@89 244
cannam@89 245 CMF (Compression Method and flags)
cannam@89 246 This byte is divided into a 4-bit compression method and a 4-
cannam@89 247 bit information field depending on the compression method.
cannam@89 248
cannam@89 249 bits 0 to 3 CM Compression method
cannam@89 250 bits 4 to 7 CINFO Compression info
cannam@89 251
cannam@89 252 CM (Compression method)
cannam@89 253 This identifies the compression method used in the file. CM = 8
cannam@89 254 denotes the "deflate" compression method with a window size up
cannam@89 255 to 32K. This is the method used by gzip and PNG (see
cannam@89 256 references [1] and [2] in Chapter 3, below, for the reference
cannam@89 257 documents). CM = 15 is reserved. It might be used in a future
cannam@89 258 version of this specification to indicate the presence of an
cannam@89 259 extra field before the compressed data.
cannam@89 260
cannam@89 261 CINFO (Compression info)
cannam@89 262 For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
cannam@89 263 size, minus eight (CINFO=7 indicates a 32K window size). Values
cannam@89 264 of CINFO above 7 are not allowed in this version of the
cannam@89 265 specification. CINFO is not defined in this specification for
cannam@89 266 CM not equal to 8.
cannam@89 267
cannam@89 268 FLG (FLaGs)
cannam@89 269 This flag byte is divided as follows:
cannam@89 270
cannam@89 271 bits 0 to 4 FCHECK (check bits for CMF and FLG)
cannam@89 272 bit 5 FDICT (preset dictionary)
cannam@89 273 bits 6 to 7 FLEVEL (compression level)
cannam@89 274
cannam@89 275 The FCHECK value must be such that CMF and FLG, when viewed as
cannam@89 276 a 16-bit unsigned integer stored in MSB order (CMF*256 + FLG),
cannam@89 277 is a multiple of 31.
cannam@89 278
cannam@89 279
cannam@89 280
cannam@89 281
cannam@89 282 Deutsch & Gailly Informational [Page 5]
cannam@89 283
cannam@89 284 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 285
cannam@89 286
cannam@89 287 FDICT (Preset dictionary)
cannam@89 288 If FDICT is set, a DICT dictionary identifier is present
cannam@89 289 immediately after the FLG byte. The dictionary is a sequence of
cannam@89 290 bytes which are initially fed to the compressor without
cannam@89 291 producing any compressed output. DICT is the Adler-32 checksum
cannam@89 292 of this sequence of bytes (see the definition of ADLER32
cannam@89 293 below). The decompressor can use this identifier to determine
cannam@89 294 which dictionary has been used by the compressor.
cannam@89 295
cannam@89 296 FLEVEL (Compression level)
cannam@89 297 These flags are available for use by specific compression
cannam@89 298 methods. The "deflate" method (CM = 8) sets these flags as
cannam@89 299 follows:
cannam@89 300
cannam@89 301 0 - compressor used fastest algorithm
cannam@89 302 1 - compressor used fast algorithm
cannam@89 303 2 - compressor used default algorithm
cannam@89 304 3 - compressor used maximum compression, slowest algorithm
cannam@89 305
cannam@89 306 The information in FLEVEL is not needed for decompression; it
cannam@89 307 is there to indicate if recompression might be worthwhile.
cannam@89 308
cannam@89 309 compressed data
cannam@89 310 For compression method 8, the compressed data is stored in the
cannam@89 311 deflate compressed data format as described in the document
cannam@89 312 "DEFLATE Compressed Data Format Specification" by L. Peter
cannam@89 313 Deutsch. (See reference [3] in Chapter 3, below)
cannam@89 314
cannam@89 315 Other compressed data formats are not specified in this version
cannam@89 316 of the zlib specification.
cannam@89 317
cannam@89 318 ADLER32 (Adler-32 checksum)
cannam@89 319 This contains a checksum value of the uncompressed data
cannam@89 320 (excluding any dictionary data) computed according to Adler-32
cannam@89 321 algorithm. This algorithm is a 32-bit extension and improvement
cannam@89 322 of the Fletcher algorithm, used in the ITU-T X.224 / ISO 8073
cannam@89 323 standard. See references [4] and [5] in Chapter 3, below)
cannam@89 324
cannam@89 325 Adler-32 is composed of two sums accumulated per byte: s1 is
cannam@89 326 the sum of all bytes, s2 is the sum of all s1 values. Both sums
cannam@89 327 are done modulo 65521. s1 is initialized to 1, s2 to zero. The
cannam@89 328 Adler-32 checksum is stored as s2*65536 + s1 in most-
cannam@89 329 significant-byte first (network) order.
cannam@89 330
cannam@89 331
cannam@89 332
cannam@89 333
cannam@89 334
cannam@89 335
cannam@89 336
cannam@89 337
cannam@89 338 Deutsch & Gailly Informational [Page 6]
cannam@89 339
cannam@89 340 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 341
cannam@89 342
cannam@89 343 2.3. Compliance
cannam@89 344
cannam@89 345 A compliant compressor must produce streams with correct CMF, FLG
cannam@89 346 and ADLER32, but need not support preset dictionaries. When the
cannam@89 347 zlib data format is used as part of another standard data format,
cannam@89 348 the compressor may use only preset dictionaries that are specified
cannam@89 349 by this other data format. If this other format does not use the
cannam@89 350 preset dictionary feature, the compressor must not set the FDICT
cannam@89 351 flag.
cannam@89 352
cannam@89 353 A compliant decompressor must check CMF, FLG, and ADLER32, and
cannam@89 354 provide an error indication if any of these have incorrect values.
cannam@89 355 A compliant decompressor must give an error indication if CM is
cannam@89 356 not one of the values defined in this specification (only the
cannam@89 357 value 8 is permitted in this version), since another value could
cannam@89 358 indicate the presence of new features that would cause subsequent
cannam@89 359 data to be interpreted incorrectly. A compliant decompressor must
cannam@89 360 give an error indication if FDICT is set and DICTID is not the
cannam@89 361 identifier of a known preset dictionary. A decompressor may
cannam@89 362 ignore FLEVEL and still be compliant. When the zlib data format
cannam@89 363 is being used as a part of another standard format, a compliant
cannam@89 364 decompressor must support all the preset dictionaries specified by
cannam@89 365 the other format. When the other format does not use the preset
cannam@89 366 dictionary feature, a compliant decompressor must reject any
cannam@89 367 stream in which the FDICT flag is set.
cannam@89 368
cannam@89 369 3. References
cannam@89 370
cannam@89 371 [1] Deutsch, L.P.,"GZIP Compressed Data Format Specification",
cannam@89 372 available in ftp://ftp.uu.net/pub/archiving/zip/doc/
cannam@89 373
cannam@89 374 [2] Thomas Boutell, "PNG (Portable Network Graphics) specification",
cannam@89 375 available in ftp://ftp.uu.net/graphics/png/documents/
cannam@89 376
cannam@89 377 [3] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
cannam@89 378 available in ftp://ftp.uu.net/pub/archiving/zip/doc/
cannam@89 379
cannam@89 380 [4] Fletcher, J. G., "An Arithmetic Checksum for Serial
cannam@89 381 Transmissions," IEEE Transactions on Communications, Vol. COM-30,
cannam@89 382 No. 1, January 1982, pp. 247-252.
cannam@89 383
cannam@89 384 [5] ITU-T Recommendation X.224, Annex D, "Checksum Algorithms,"
cannam@89 385 November, 1993, pp. 144, 145. (Available from
cannam@89 386 gopher://info.itu.ch). ITU-T X.244 is also the same as ISO 8073.
cannam@89 387
cannam@89 388
cannam@89 389
cannam@89 390
cannam@89 391
cannam@89 392
cannam@89 393
cannam@89 394 Deutsch & Gailly Informational [Page 7]
cannam@89 395
cannam@89 396 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 397
cannam@89 398
cannam@89 399 4. Source code
cannam@89 400
cannam@89 401 Source code for a C language implementation of a "zlib" compliant
cannam@89 402 library is available at ftp://ftp.uu.net/pub/archiving/zip/zlib/.
cannam@89 403
cannam@89 404 5. Security Considerations
cannam@89 405
cannam@89 406 A decoder that fails to check the ADLER32 checksum value may be
cannam@89 407 subject to undetected data corruption.
cannam@89 408
cannam@89 409 6. Acknowledgements
cannam@89 410
cannam@89 411 Trademarks cited in this document are the property of their
cannam@89 412 respective owners.
cannam@89 413
cannam@89 414 Jean-Loup Gailly and Mark Adler designed the zlib format and wrote
cannam@89 415 the related software described in this specification. Glenn
cannam@89 416 Randers-Pehrson converted this document to RFC and HTML format.
cannam@89 417
cannam@89 418 7. Authors' Addresses
cannam@89 419
cannam@89 420 L. Peter Deutsch
cannam@89 421 Aladdin Enterprises
cannam@89 422 203 Santa Margarita Ave.
cannam@89 423 Menlo Park, CA 94025
cannam@89 424
cannam@89 425 Phone: (415) 322-0103 (AM only)
cannam@89 426 FAX: (415) 322-1734
cannam@89 427 EMail: <ghost@aladdin.com>
cannam@89 428
cannam@89 429
cannam@89 430 Jean-Loup Gailly
cannam@89 431
cannam@89 432 EMail: <gzip@prep.ai.mit.edu>
cannam@89 433
cannam@89 434 Questions about the technical content of this specification can be
cannam@89 435 sent by email to
cannam@89 436
cannam@89 437 Jean-Loup Gailly <gzip@prep.ai.mit.edu> and
cannam@89 438 Mark Adler <madler@alumni.caltech.edu>
cannam@89 439
cannam@89 440 Editorial comments on this specification can be sent by email to
cannam@89 441
cannam@89 442 L. Peter Deutsch <ghost@aladdin.com> and
cannam@89 443 Glenn Randers-Pehrson <randeg@alumni.rpi.edu>
cannam@89 444
cannam@89 445
cannam@89 446
cannam@89 447
cannam@89 448
cannam@89 449
cannam@89 450 Deutsch & Gailly Informational [Page 8]
cannam@89 451
cannam@89 452 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 453
cannam@89 454
cannam@89 455 8. Appendix: Rationale
cannam@89 456
cannam@89 457 8.1. Preset dictionaries
cannam@89 458
cannam@89 459 A preset dictionary is specially useful to compress short input
cannam@89 460 sequences. The compressor can take advantage of the dictionary
cannam@89 461 context to encode the input in a more compact manner. The
cannam@89 462 decompressor can be initialized with the appropriate context by
cannam@89 463 virtually decompressing a compressed version of the dictionary
cannam@89 464 without producing any output. However for certain compression
cannam@89 465 algorithms such as the deflate algorithm this operation can be
cannam@89 466 achieved without actually performing any decompression.
cannam@89 467
cannam@89 468 The compressor and the decompressor must use exactly the same
cannam@89 469 dictionary. The dictionary may be fixed or may be chosen among a
cannam@89 470 certain number of predefined dictionaries, according to the kind
cannam@89 471 of input data. The decompressor can determine which dictionary has
cannam@89 472 been chosen by the compressor by checking the dictionary
cannam@89 473 identifier. This document does not specify the contents of
cannam@89 474 predefined dictionaries, since the optimal dictionaries are
cannam@89 475 application specific. Standard data formats using this feature of
cannam@89 476 the zlib specification must precisely define the allowed
cannam@89 477 dictionaries.
cannam@89 478
cannam@89 479 8.2. The Adler-32 algorithm
cannam@89 480
cannam@89 481 The Adler-32 algorithm is much faster than the CRC32 algorithm yet
cannam@89 482 still provides an extremely low probability of undetected errors.
cannam@89 483
cannam@89 484 The modulo on unsigned long accumulators can be delayed for 5552
cannam@89 485 bytes, so the modulo operation time is negligible. If the bytes
cannam@89 486 are a, b, c, the second sum is 3a + 2b + c + 3, and so is position
cannam@89 487 and order sensitive, unlike the first sum, which is just a
cannam@89 488 checksum. That 65521 is prime is important to avoid a possible
cannam@89 489 large class of two-byte errors that leave the check unchanged.
cannam@89 490 (The Fletcher checksum uses 255, which is not prime and which also
cannam@89 491 makes the Fletcher check insensitive to single byte changes 0 <->
cannam@89 492 255.)
cannam@89 493
cannam@89 494 The sum s1 is initialized to 1 instead of zero to make the length
cannam@89 495 of the sequence part of s2, so that the length does not have to be
cannam@89 496 checked separately. (Any sequence of zeroes has a Fletcher
cannam@89 497 checksum of zero.)
cannam@89 498
cannam@89 499
cannam@89 500
cannam@89 501
cannam@89 502
cannam@89 503
cannam@89 504
cannam@89 505
cannam@89 506 Deutsch & Gailly Informational [Page 9]
cannam@89 507
cannam@89 508 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 509
cannam@89 510
cannam@89 511 9. Appendix: Sample code
cannam@89 512
cannam@89 513 The following C code computes the Adler-32 checksum of a data buffer.
cannam@89 514 It is written for clarity, not for speed. The sample code is in the
cannam@89 515 ANSI C programming language. Non C users may find it easier to read
cannam@89 516 with these hints:
cannam@89 517
cannam@89 518 & Bitwise AND operator.
cannam@89 519 >> Bitwise right shift operator. When applied to an
cannam@89 520 unsigned quantity, as here, right shift inserts zero bit(s)
cannam@89 521 at the left.
cannam@89 522 << Bitwise left shift operator. Left shift inserts zero
cannam@89 523 bit(s) at the right.
cannam@89 524 ++ "n++" increments the variable n.
cannam@89 525 % modulo operator: a % b is the remainder of a divided by b.
cannam@89 526
cannam@89 527 #define BASE 65521 /* largest prime smaller than 65536 */
cannam@89 528
cannam@89 529 /*
cannam@89 530 Update a running Adler-32 checksum with the bytes buf[0..len-1]
cannam@89 531 and return the updated checksum. The Adler-32 checksum should be
cannam@89 532 initialized to 1.
cannam@89 533
cannam@89 534 Usage example:
cannam@89 535
cannam@89 536 unsigned long adler = 1L;
cannam@89 537
cannam@89 538 while (read_buffer(buffer, length) != EOF) {
cannam@89 539 adler = update_adler32(adler, buffer, length);
cannam@89 540 }
cannam@89 541 if (adler != original_adler) error();
cannam@89 542 */
cannam@89 543 unsigned long update_adler32(unsigned long adler,
cannam@89 544 unsigned char *buf, int len)
cannam@89 545 {
cannam@89 546 unsigned long s1 = adler & 0xffff;
cannam@89 547 unsigned long s2 = (adler >> 16) & 0xffff;
cannam@89 548 int n;
cannam@89 549
cannam@89 550 for (n = 0; n < len; n++) {
cannam@89 551 s1 = (s1 + buf[n]) % BASE;
cannam@89 552 s2 = (s2 + s1) % BASE;
cannam@89 553 }
cannam@89 554 return (s2 << 16) + s1;
cannam@89 555 }
cannam@89 556
cannam@89 557 /* Return the adler32 of the bytes buf[0..len-1] */
cannam@89 558
cannam@89 559
cannam@89 560
cannam@89 561
cannam@89 562 Deutsch & Gailly Informational [Page 10]
cannam@89 563
cannam@89 564 RFC 1950 ZLIB Compressed Data Format Specification May 1996
cannam@89 565
cannam@89 566
cannam@89 567 unsigned long adler32(unsigned char *buf, int len)
cannam@89 568 {
cannam@89 569 return update_adler32(1L, buf, len);
cannam@89 570 }
cannam@89 571
cannam@89 572
cannam@89 573
cannam@89 574
cannam@89 575
cannam@89 576
cannam@89 577
cannam@89 578
cannam@89 579
cannam@89 580
cannam@89 581
cannam@89 582
cannam@89 583
cannam@89 584
cannam@89 585
cannam@89 586
cannam@89 587
cannam@89 588
cannam@89 589
cannam@89 590
cannam@89 591
cannam@89 592
cannam@89 593
cannam@89 594
cannam@89 595
cannam@89 596
cannam@89 597
cannam@89 598
cannam@89 599
cannam@89 600
cannam@89 601
cannam@89 602
cannam@89 603
cannam@89 604
cannam@89 605
cannam@89 606
cannam@89 607
cannam@89 608
cannam@89 609
cannam@89 610
cannam@89 611
cannam@89 612
cannam@89 613
cannam@89 614
cannam@89 615
cannam@89 616
cannam@89 617
cannam@89 618 Deutsch & Gailly Informational [Page 11]
cannam@89 619