lzip-bug
[Top][All Lists]
Advanced

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

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


From: Tino Lange
Subject: [Lzip-bug] lzlib: Question/Remarks about some API Signatures
Date: Tue, 01 Sep 2009 09:09:26 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

Hi Antonio, hi List,

While working with lzlib I noticed the following two points and would
like to write them down for you and ask some related questions:

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:

> Function: int LZ_compress_write ( void * const encoder, const uint8_t * const 
> buffer, const int size )
> Function: int LZ_decompress_write ( void * const decoder, const uint8_t * 
> const buffer, const int size )

At the moment I need to do ugly const_casts in my test program when
using those LZ_*_write() functions. I can't see any reason for using
non-const buffers here?

2) Why does the function family

>  long long LZ_compress_data_position ( void * const encoder )
>  long long LZ_compress_member_position ( void * const encoder )
>  long long LZ_compress_total_in_size ( void * const encoder )
>  long long LZ_compress_total_out_size ( void * const encoder )
>  long long LZ_decompress_data_position ( void * const decoder )
>  long long LZ_decompress_member_position ( void * const decoder )
>  long long LZ_decompress_total_in_size ( void * const decoder )
>  long long LZ_decompress_total_out_size ( void * const decoder )

return a signed value? Wouldn't ~0ULL for the error be enough?

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

Thanks for your help and cheers,

Tino




reply via email to

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