[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lzip-bug] lzlib: Question/Remarks about some API Signatures

From: Antonio Diaz Diaz
Subject: Re: [Lzip-bug] lzlib: Question/Remarks about some API Signatures
Date: Tue, 01 Sep 2009 17:12:22 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

John Reiser wrote:
A signed value is consistent with the rest of the library functions. All
of them return -1 on error.

I often desire more precise information about what was wrong.  I prefer
an error code which gives a good clue about how to fix the problem.

From lzlib.info (Error Codes):
"Most library functions return -1 to indicate that they have failed. But
this return value only tells you that an error has occurred. To find out
what kind of error it was, you need to verify the error code by calling

Lzlib compresses on read, so you can write a lot of data and
LZ_compress_data_position will still return 0.

It seems to me that compressing only on demand (that is, only upon
executing a 'read' operation on the compressed stream) is a policy
decision.  This policy has some advantages, including postponing work
which might be avoidable.  But it has some disadvantages, including
long latency at the first read.  I favor the option to choose the policy,
all the way from "as late as possible" to "as soon as possible".
In the particular case of lzlib, it seems to me that a good intermediate
policy would be to limit not-yet-compressed data to at most the size
of the dictionary (or the look-back window), or perhaps twice that much.

Then you will like to know that 1) you can choose the policy by issuing zero-sized read commands, and 2) lzlib already limits not-yet-compressed data to at most twice the size of the dictionary. (See "Buffering" in lzlib.info).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]