|
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 `LZ_(de)compress_errno'."
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).
Regards, Antonio.
[Prev in Thread] | Current Thread | [Next in Thread] |