lzip-bug
[Top][All Lists]
Advanced

[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 15:26:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

Hello Tino,

Tino Lange wrote:
1) shouldn't
Function: int LZ_compress_write   ( void * const encoder, uint8_t * const 
buffer, const int size )
Function: int LZ_decompress_write ( void * const decoder, uint8_t * const 
buffer, const int size )
be changed to use a const buffer (as it's really only read from it), i.e:

Done. Thanks for reporting this.


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.


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. (LZ_compress_member_position returns 6, the size of the member header). I'll explain this in the documentation.

BTW, I have already fixed the flush problem. I'll release a corrected version tomorrow or so. (Sorry, but there is no repository for lzlib). In the meantime you can try calling LZ_compress_sync_flush 4 consecutive times.


Regards,
Antonio.




reply via email to

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