home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / compress / 3869 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  1.2 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!data.nas.nasa.gov!mustang.mst6.lanl.gov!nntp-server.caltech.edu!madler
  2. From: madler@cco.caltech.edu (Mark Adler)
  3. Newsgroups: comp.compression
  4. Subject: Re: Unzip50 bug??
  5. Date: 16 Nov 1992 22:12:48 GMT
  6. Organization: California Institute of Technology, Pasadena
  7. Lines: 18
  8. Message-ID: <1e96d0INNd9b@gap.caltech.edu>
  9. References: <1dunluINNekd@usenet.INS.CWRU.Edu>
  10. NNTP-Posting-Host: sandman.caltech.edu
  11.  
  12.  
  13. Yes, I would call that an Unzip 5.0 bug.  Currently unzip does not
  14. stop when it exceeds the uncompressed byte count--it assumes that
  15. the input data is good, and that it will get an end-of-block marker
  16. in the compressed data.  This is only true for the deflate method,
  17. since the other methods don't have end-markers, they depend on the
  18. counts (compressed or uncompressed) to stop.
  19.  
  20. This was partly a speed trade-off, and partly laziness.  I will look
  21. into putting checks for compressed and uncompressed sizes.
  22.  
  23. This will always be a problem for funzip, since a filter generated
  24. zip file doesn't have the sizes at the start, since they are not
  25. known at the start.  funzip will continue to depend on the markers
  26. in the compressed stream.
  27.  
  28. Mark Adler
  29. madler@cco.caltech.edu
  30.