[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: John Reiser
Subject: Re: [Lzip-bug] lzlib: Question/Remarks about some API Signatures
Date: Tue, 01 Sep 2009 07:06:50 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

2) Why does the function family
long long LZ_compress_data_position ( void * const encoder )
return a signed value? Wouldn't ~0ULL for the error be enough?

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.
I like the scheme used by the Linux kernel, where error codes are
integers -1, -2, ... -4095; which is the same as unsigned greater than

Also there should IMHO be some remark in the documentation that at least
for the compress functions all the numbers are correct only after flush
(if it would be working :-) ) or finish has been called. Before there
can be even 0 or 6 as result although quite large amounts of data have
already been sucessfully compressed with write/read. This might be
confusing (at least it was for me yesterday ... :-) )

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.


reply via email to

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