Re: MFH for 2 zlib patches?

On Wed, 13 Mar 2002, Stefan Roehrich wrote: > Hello Derick! > > Yesterday I committed two patches for ext/zlib/ to HEAD, because they > fixed two bugs, I wanted to ask, if I should commit them to the 4.2 > branch. > > The first one works around a rather curious behaviour of zlib, under > some circumstances zlib wants to read one byte more than necessary and > so returns a buffer error, because it can't read this byte. As a (not > so nice) solution I allow zlib to read one byte more, this doesn't > seem to hurt, it worked in my tests and if you get the input e.g. from > gzdeflate() you have this trailing byte because an additional appended > \0. I don't like this solution (I had no time to look through whole > PHP if we have always this additional byte), but I wanted to avoid > copying the whole input into a buffer which is one byte larger ... Strings used in the PHP zval container should always be \0 terminated, so this not a problem. (Unless another module screws things up). This fix should go in. > > The second patch is a reimplementation of gzencode() (it's not really > new code, is a recombination of code from the old gzencode() and from > gzdeflate()), it fixes a documentation bug, because gzencode() was > misdocumented, the second parameter is documented as the compression > level, but it was an encoding mode (which I think is rather > meaningless). So I changed it to accept the compression level as > second parameter and the encoding mode as new third (optional) > parameter (I asked about the sequence of the parameters in php-dev and > php-doc but got no response). I also think that there could be some > bugs, if you use gzencode() with output compression enabled, that > shouldn't be a problem in the new version, whose output (at least for > small input) is more similar to the "real" gzip output. > > What do you think? I think this can be merged too. WOuld you be so kind to hand over some test cases (more than just the tests dir) to the QA team, so this can be properly tested during RCs? regards, Derick --------------------------------------------------------------------- PHP: Scripting the Web - www.php.net - derick@php.net SRM: Site Resource Manager - www.vl-srm.net --------------------------------------------------------------------- JDI Media Solutions - www.jdimedia.nl - d.rethans@jdimedia.nl Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands ---------------------------------------------------------------------