lkml.org 
[lkml]   [2005]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] CryptoAPI & Compression
    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?
    It must not. Look at the algoritm closer.

    stream->next_in = (u8 *)src;
    stream->next_out = dst;

    while (stream->total_in < *slen
    && stream->total_out < *dlen - DEFLATE_PCOMPR_RESERVE) {

    stream->avail_out = *dlen - DEFLATE_PCOMPR_RESERVE -
    stream->total_out;
    stream->avail_in = min((unsigned int)(*slen -
    stream->total_in), stream->avail_out);

    ret = zlib_deflate(stream, Z_SYNC_FLUSH);
    if (ret != Z_OK)
    return -EINVAL;
    }

    stream->avail_out += DEFLATE_PCOMPR_RESERVE;
    stream->avail_in = 0; /* <------ no more input ! ---------- */

    ret = zlib_deflate(stream, Z_FINISH);
    if (ret != Z_STREAM_END)
    return -EINVAL;



    >
    > When it does return it has to finish writing the last block it's on.
    No, it must only put EOB and adler32, we won't give it more input.

    --
    Best Regards,
    Artem B. Bityuckiy,
    St.-Petersburg, Russia.
    -
    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/

    \
     
     \ /
      Last update: 2005-04-06 13:31    [W:4.371 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site