Ollie Lho <[EMAIL PROTECTED]> writes: > O.K. I don't know much about gzip. Do you have any idea why the > bug can be cured by different compression level ?? If the bug is > at as low level as stream interface evey compress level should > be affected, am I right ??
O.k. My review is complete and there is nothing obviously wrong with our small changes to inflate.c compared against gzip-1.2.4a. The biggest difference is in makecrc where we calculate the crc values. We exactly match the linux kernel there, so I suspect we are just using an older algorithm. Hmm. gzip does call malloc so without the docmil update a buffer overrun could be a problem. With a different compression level the pattern of mallocs use by inflate.c would be different. It would be nice to see if code that does not decompress from LinuxBIOS could be placed in a file and tested with gunzip. We may actually be experience intermittent data failure. The most interesting thing is the buffer overflow in memcpy_from_docmil has existed since the code was added to CVS. So historically small bugs in the stream driver might not show immediately. At any rate that is enough of that for now... Eric
