FAQ (145474) | FAQ (157043) |
---|---|
1 2 Frequently Asked Questions about zlib 3 4 5If your question is not there, please check the zlib home page 6http://www.zlib.org which may have more recent information. 7The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html 8 --- 134 unchanged lines hidden (view full) --- 143 uses a faster integrity check than gzip. 144 14520. Well that's nice, but how do I make a gzip file in memory? 146 147 You can request that deflate write the gzip format instead of the zlib 148 format using deflateInit2(). You can also request that inflate decode 149 the gzip format using inflateInit2(). Read zlib.h for more details. 150 | 1 2 Frequently Asked Questions about zlib 3 4 5If your question is not there, please check the zlib home page 6http://www.zlib.org which may have more recent information. 7The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html 8 --- 134 unchanged lines hidden (view full) --- 143 uses a faster integrity check than gzip. 144 14520. Well that's nice, but how do I make a gzip file in memory? 146 147 You can request that deflate write the gzip format instead of the zlib 148 format using deflateInit2(). You can also request that inflate decode 149 the gzip format using inflateInit2(). Read zlib.h for more details. 150 |
151 Note that you cannot specify special gzip header contents (e.g. a file 152 name or modification date), nor will inflate tell you what was in the 153 gzip header. If you need to customize the header or see what's in it, 154 you can use the raw deflate and inflate operations and the crc32() 155 function and roll your own gzip encoding and decoding. Read the gzip 156 RFC 1952 for details of the header and trailer format. 157 | |
15821. Is zlib thread-safe? 159 160 Yes. However any library routines that zlib uses and any application- 161 provided memory allocation routines must also be thread-safe. zlib's gz* 162 functions use stdio library routines, and most of zlib's functions use the 163 library memory allocation routines by default. zlib's Init functions allow 164 for the application to provide custom memory allocation routines. 165 --- 124 unchanged lines hidden (view full) --- 29035. I get this or that compiler or source-code scanner warning when I crank it 291 up to maximally-pedantic. Can't you guys write proper code? 292 293 Many years ago, we gave up attempting to avoid warnings on every compiler 294 in the universe. It just got to be a waste of time, and some compilers 295 were downright silly. So now, we simply make sure that the code always 296 works. 297 | 15121. Is zlib thread-safe? 152 153 Yes. However any library routines that zlib uses and any application- 154 provided memory allocation routines must also be thread-safe. zlib's gz* 155 functions use stdio library routines, and most of zlib's functions use the 156 library memory allocation routines by default. zlib's Init functions allow 157 for the application to provide custom memory allocation routines. 158 --- 124 unchanged lines hidden (view full) --- 28335. I get this or that compiler or source-code scanner warning when I crank it 284 up to maximally-pedantic. Can't you guys write proper code? 285 286 Many years ago, we gave up attempting to avoid warnings on every compiler 287 in the universe. It just got to be a waste of time, and some compilers 288 were downright silly. So now, we simply make sure that the code always 289 works. 290 |
29836. Will zlib read the (insert any ancient or arcane format here) compressed | 29136. Valgrind (or some similar memory access checker) says that deflate is 292 performing a conditional jump that depends on an uninitialized value. 293 Isn't that a bug? 294 295 No. That is intentional for performance reasons, and the output of 296 deflate is not affected. This only started showing up recently since 297 zlib 1.2.x uses malloc() by default for allocations, whereas earlier 298 versions used calloc(), which zeros out the allocated memory. 299 30037. Will zlib read the (insert any ancient or arcane format here) compressed |
299 data format? 300 301 Probably not. Look in the comp.compression FAQ for pointers to various 302 formats and associated software. 303 | 301 data format? 302 303 Probably not. Look in the comp.compression FAQ for pointers to various 304 formats and associated software. 305 |
30437. How can I encrypt/decrypt zip files with zlib? | 30638. How can I encrypt/decrypt zip files with zlib? |
305 306 zlib doesn't support encryption. The original PKZIP encryption is very weak 307 and can be broken with freely available programs. To get strong encryption, 308 use GnuPG, http://www.gnupg.org/ , which already includes zlib compression. 309 For PKZIP compatible "encryption", look at http://www.info-zip.org/ 310 | 307 308 zlib doesn't support encryption. The original PKZIP encryption is very weak 309 and can be broken with freely available programs. To get strong encryption, 310 use GnuPG, http://www.gnupg.org/ , which already includes zlib compression. 311 For PKZIP compatible "encryption", look at http://www.info-zip.org/ 312 |
31138. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings? | 31339. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings? |
312 313 "gzip" is the gzip format, and "deflate" is the zlib format. They should 314 probably have called the second one "zlib" instead to avoid confusion 315 with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616 316 correctly points to the zlib specification in RFC 1950 for the "deflate" 317 transfer encoding, there have been reports of servers and browsers that 318 incorrectly produce or expect raw deflate data per the deflate 319 specficiation in RFC 1951, most notably Microsoft. So even though the 320 "deflate" transfer encoding using the zlib format would be the more 321 efficient approach (and in fact exactly what the zlib format was designed 322 for), using the "gzip" transfer encoding is probably more reliable due to 323 an unfortunate choice of name on the part of the HTTP 1.1 authors. 324 325 Bottom line: use the gzip format for HTTP 1.1 encoding. 326 | 314 315 "gzip" is the gzip format, and "deflate" is the zlib format. They should 316 probably have called the second one "zlib" instead to avoid confusion 317 with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616 318 correctly points to the zlib specification in RFC 1950 for the "deflate" 319 transfer encoding, there have been reports of servers and browsers that 320 incorrectly produce or expect raw deflate data per the deflate 321 specficiation in RFC 1951, most notably Microsoft. So even though the 322 "deflate" transfer encoding using the zlib format would be the more 323 efficient approach (and in fact exactly what the zlib format was designed 324 for), using the "gzip" transfer encoding is probably more reliable due to 325 an unfortunate choice of name on the part of the HTTP 1.1 authors. 326 327 Bottom line: use the gzip format for HTTP 1.1 encoding. 328 |
32739. Does zlib support the new "Deflate64" format introduced by PKWare? | 32940. Does zlib support the new "Deflate64" format introduced by PKWare? |
328 329 No. PKWare has apparently decided to keep that format proprietary, since 330 they have not documented it as they have previous compression formats. 331 In any case, the compression improvements are so modest compared to other 332 more modern approaches, that it's not worth the effort to implement. 333 | 330 331 No. PKWare has apparently decided to keep that format proprietary, since 332 they have not documented it as they have previous compression formats. 333 In any case, the compression improvements are so modest compared to other 334 more modern approaches, that it's not worth the effort to implement. 335 |
33440. Can you please sign these lengthy legal documents and fax them back to us | 33641. Can you please sign these lengthy legal documents and fax them back to us |
335 so that we can use your software in our product? 336 337 No. Go away. Shoo. | 337 so that we can use your software in our product? 338 339 No. Go away. Shoo. |