diff options
Diffstat (limited to 'FAQ')
-rw-r--r-- | FAQ | 52 |
1 files changed, 33 insertions, 19 deletions
@@ -20,7 +20,7 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
20 | 3. Where can I get a Visual Basic interface to zlib? | 20 | 3. Where can I get a Visual Basic interface to zlib? |
21 | 21 | ||
22 | See | 22 | See |
23 | * http://www.winimage.com/zLibDll/cmp-z-it.zip | 23 | * http://www.winimage.com/zLibDll/ |
24 | * http://www.dogma.net/markn/articles/zlibtool/zlibtool.htm | 24 | * http://www.dogma.net/markn/articles/zlibtool/zlibtool.htm |
25 | * contrib/visual-basic.txt in the zlib distribution | 25 | * contrib/visual-basic.txt in the zlib distribution |
26 | 26 | ||
@@ -147,11 +147,14 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
147 | 22. The license says that altered source versions must be "plainly marked". So | 147 | 22. The license says that altered source versions must be "plainly marked". So |
148 | what exactly do I need to do to meet that requirement? | 148 | what exactly do I need to do to meet that requirement? |
149 | 149 | ||
150 | You need to append something the ZLIB_VERSION string in zlib.h. For | 150 | You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h. In |
151 | example, if the version of the base zlib you are altering is "1.2.3", then | 151 | particular, the final version number needs to be changed to "f", and an |
152 | you could change the string to "1.2.3-fred-mods-v3". You should not change | 152 | identification string should be appended to ZLIB_VERSION. Version numbers |
153 | it to "1.2.4" or "1.2.3.1" since the zlib authors would like to reserve | 153 | x.x.x.f are reserved for modifications to zlib by others than the zlib |
154 | those forms of the version for their own use. | 154 | maintainers. For example, if the version of the base zlib you are altering |
155 | is "1.2.3.4", then in zlib.h you should change ZLIB_VERNUM to 0x123f, and | ||
156 | ZLIB_VERSION to something like "1.2.3.f-zachary-mods-v3". You can also | ||
157 | update the version strings in deflate.c and inftrees.c. | ||
155 | 158 | ||
156 | For altered source distributions, you should also note the origin and | 159 | For altered source distributions, you should also note the origin and |
157 | nature of the changes in zlib.h, as well as in ChangeLog and README, along | 160 | nature of the changes in zlib.h, as well as in ChangeLog and README, along |
@@ -161,8 +164,8 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
161 | 164 | ||
162 | Note that distributing a compiled zlib library along with zlib.h and | 165 | Note that distributing a compiled zlib library along with zlib.h and |
163 | zconf.h is also a source distribution, and so you should change | 166 | zconf.h is also a source distribution, and so you should change |
164 | ZLIB_VERSION and note the origin and nature of the changes in zlib.h as you | 167 | ZLIB_VERSION and ZLIB_VERNUM and note the origin and nature of the changes |
165 | would for a full source distribution. | 168 | in zlib.h as you would for a full source distribution. |
166 | 169 | ||
167 | 23. Will zlib work on a big-endian or little-endian architecture, and can I | 170 | 23. Will zlib work on a big-endian or little-endian architecture, and can I |
168 | exchange compressed data between them? | 171 | exchange compressed data between them? |
@@ -212,12 +215,20 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
212 | 30. Can zlib work with greater than 4 GB of data? | 215 | 30. Can zlib work with greater than 4 GB of data? |
213 | 216 | ||
214 | Yes. inflate() and deflate() will process any amount of data correctly. | 217 | Yes. inflate() and deflate() will process any amount of data correctly. |
215 | However the strm.total_in and strm_total_out counters may be limited to | 218 | Each call of inflate() or deflate() is limited to input and output chunks |
216 | 4 GB. The application can easily set up its own counters updated after each | 219 | of the maximum value that can be stored in the compiler's "unsigned int" |
217 | call of inflate() or deflate() to count beyond 4 GB. compress() and | 220 | type, but there is no limit to the number of chunks. Note however that the |
218 | uncompress() may be limited to 4 GB, since they operate in a single call | 221 | strm.total_in and strm_total_out counters may be limited to 4 GB. These |
219 | using unsigned long lengths. gzseek() and gztell() may be limited to 4 GB | 222 | counters are provided as a convenience and are not used internally by |
220 | depending on how zlib is compiled. | 223 | inflate() or deflate(). The application can easily set up its own counters |
224 | updated after each call of inflate() or deflate() to count beyond 4 GB. | ||
225 | compress() and uncompress() may be limited to 4 GB, since they operate in a | ||
226 | single call. gzseek() and gztell() may be limited to 4 GB depending on how | ||
227 | zlib is compiled. See the zlibCompileFlags() function in zlib.h. | ||
228 | |||
229 | The word "may" appears several times above since there is a 4 GB limit | ||
230 | only if the compiler's "long" type is 32 bits. If the compiler's "long" | ||
231 | type is 64 bits, then the limit is 16 exabytes. | ||
221 | 232 | ||
222 | 31. Does zlib have any security vulnerabilities? | 233 | 31. Does zlib have any security vulnerabilities? |
223 | 234 | ||
@@ -228,7 +239,7 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
228 | hand, if zlib is compiled to use snprintf() or vsnprintf(), which should | 239 | hand, if zlib is compiled to use snprintf() or vsnprintf(), which should |
229 | normally be the case, then there is no vulnerability. The ./configure | 240 | normally be the case, then there is no vulnerability. The ./configure |
230 | script will display warnings if an insecure variation of sprintf() will | 241 | script will display warnings if an insecure variation of sprintf() will |
231 | be used by gzprintf(). Also the zlibCompileFlags() functions will return | 242 | be used by gzprintf(). Also the zlibCompileFlags() function will return |
232 | information on what variant of sprintf() is used by gzprintf(). | 243 | information on what variant of sprintf() is used by gzprintf(). |
233 | 244 | ||
234 | If you don't have snprintf() or vsnprintf() and would like one, you can | 245 | If you don't have snprintf() or vsnprintf() and would like one, you can |
@@ -262,9 +273,10 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
262 | 273 | ||
263 | 35. How can I encrypt/decrypt zip files with zlib? | 274 | 35. How can I encrypt/decrypt zip files with zlib? |
264 | 275 | ||
265 | zlib doesn't support encryption. PKZIP encryption is very weak and can be | 276 | zlib doesn't support encryption. The original PKZIP encryption is very weak |
266 | broken with freely available programs. To get strong encryption, use gpg | 277 | and can be broken with freely available programs. To get strong encryption, |
267 | which already includes zlib compression. | 278 | use gpg ( http://www.gnupg.org/ ) which already includes zlib compression. |
279 | For PKZIP compatible "encryption", look at http://www.info-zip.org/ | ||
268 | 280 | ||
269 | 36. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings? | 281 | 36. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings? |
270 | 282 | ||
@@ -280,6 +292,8 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
280 | for), using the "gzip" transfer encoding is probably more reliable due to | 292 | for), using the "gzip" transfer encoding is probably more reliable due to |
281 | an unfortunate choice of name on the part of the HTTP 1.1 authors. | 293 | an unfortunate choice of name on the part of the HTTP 1.1 authors. |
282 | 294 | ||
295 | Bottom line: use the gzip format for HTTP 1.1 encoding. | ||
296 | |||
283 | 37. Does zlib support the new "Deflate64" format introduced by PKWare? | 297 | 37. Does zlib support the new "Deflate64" format introduced by PKWare? |
284 | 298 | ||
285 | No. PKWare has apparently decided to keep that format proprietary, since | 299 | No. PKWare has apparently decided to keep that format proprietary, since |
@@ -290,4 +304,4 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html | |||
290 | 38. Can you please sign these lengthy legal documents and fax them back to us | 304 | 38. Can you please sign these lengthy legal documents and fax them back to us |
291 | so that we can use your software in our product? | 305 | so that we can use your software in our product? |
292 | 306 | ||
293 | No. Go away. | 307 | No. Go away. Shoo. |