Messages in this thread | | | Subject | Re: [RFC] CryptoAPI & Compression | From | David Woodhouse <> | Date | Sun, 03 Apr 2005 12:19:17 +0100 |
| |
On Sun, 2005-04-03 at 20:17 +1000, Herbert Xu wrote: > You might be right. But I'm not sure yet. > > If we use the current code and supply zlib_deflate with 1048576-12 > bytes of (incompressible) input and 1048576 bytes of output buffer, > wouldn't zlib keep writing incompressible blocks and return when it > can't do that anymore because the output buffer has been exhausted? > > When it does return it has to finish writing the last block it's on. > > So if the total overhead is 32 bytes then the last block would need > another 20 bytes of output space which we don't have, no?
Right. We shouldn't feed 1048576-12 bytes into zlib and expect the output to fit into our 1048576-byte buffer. We could get away with that kind of thing when we were using Z_SYNC_FLUSH but we can't now.
But now we're not using Z_SYNC_FLUSH it doesn't matter if we feed the input in smaller chunks. We can calculate a conservative estimate of the amount we'll fit, and keep feeding it input till the amount of space left in the output buffer is 12 bytes.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |