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

[John Reiser]

> > 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
0xff...f000.

> > 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.

--