Bug #25330 for Compress-LZF: Perl-generated compressed files not compatible with liblzf

Wed Mar 07 15:23:59 2007 AGRUNDMA [...] cpan.org - Ticket created

Subject:

Perl-generated compressed files not compatible with liblzf

Hi Marc, We're trying to use LZF from Perl -> C. The data is compressed on the Perl side and decompressed by C code using liblzf. However it appears the Perl version prepends a different header that the C code doesn't understand. If there was a way to generate C-compatible files from Perl, it would be helpful.

Thu Mar 08 21:54:13 2007 AGRUNDMA [...] cpan.org - Correspondence added

From:

AGRUNDMA [...] cpan.org

FYI, here's the code I'm using to work around this issue at the moment: my $len = length($foo); my $compressed = Compress::LZF::compress($foo); if ( ord( substr $compressed, 0, 1 ) == 0 ) { # The data wasn't able to be compressed my $c_header = "ZV\0" . pack('n', $len); substr $compressed, 0, 1, $c_header; } else { my $csize = length($compressed) - 2; my $c_header = "ZV\1" . pack('n', $csize) . pack('n', $len); substr $compressed, 0, 2, $c_header; }

Sun Apr 15 02:13:22 2007 MLEHMANN [...] cpan.org - Correspondence added

On Thu Mar 08 21:54:13 2007, AGRUNDMA wrote: Show quoted text

> FYI, here's the code I'm using to work around this issue at the moment:

There is no issue: liblzf does not have a header, applications using it must add their own (for example, to store the length: The C api exposes this but leaves it up to the user of the library to care for this meta-information). The obvious way to make both interoperable is to prepend the same header that compress-lzf does, which is simply the length of the uncompressed data, UTF-8/UTF-X encoded, or 0 if the data could not be compressed (see the xs code for details). If you wrote C code to illustrate this I would be happy to include it somewhere in the documentation.

Sun Apr 15 02:14:50 2007 MLEHMANN [...] cpan.org - Correspondence added

On Thu Mar 08 21:54:13 2007, AGRUNDMA wrote: Show quoted text

> FYI, here's the code I'm using to work around this issue at the moment:

There is no issue: liblzf does not have a header, applications using it must add their own (for example, to store the length: The C api exposes this but leaves it up to the user of the library to care for this meta-information). The obvious way to make both interoperable is to prepend the same header that compress-lzf does, which is simply the length of the uncompressed data, UTF-8/UTF-X encoded, or 0 if the data could not be compressed (see the xs code for details). If you wrote C code to illustrate this I would be happy to include it somewhere in the documentation.

Sun Apr 15 02:15:45 2007 MLEHMANN [...] cpan.org - Correspondence added

On Thu Mar 08 21:54:13 2007, AGRUNDMA wrote: Show quoted text

> FYI, here's the code I'm using to work around this issue at the moment:

There is no issue: liblzf does not have a header, applications using it must add their own (for example, to store the length: The C api exposes this but leaves it up to the user of the library to care for this meta-information). The obvious way to make both interoperable is to prepend the same header that compress-lzf does, which is simply the length of the uncompressed data, UTF-8/UTF-X encoded, or 0 if the data could not be compressed (see the xs code for details). If you wrote C code to illustrate this I would be happy to include it somewhere in the documentation.

Sun Apr 15 02:16:00 2007 The RT System itself - Status changed from 'new' to 'open'

Sun Apr 15 02:16:24 2007 The RT System itself - Status changed from 'new' to 'open'

Sun Apr 15 02:16:37 2007 MLEHMANN [...] cpan.org - Status changed from 'open' to 'rejected'

Sun Apr 15 02:16:39 2007 MLEHMANN [...] cpan.org - Status changed from 'open' to 'rejected'

Sun Apr 15 02:21:53 2007 MLEHMANN [...] cpan.org - Correspondence added

On Thu Mar 08 21:54:13 2007, AGRUNDMA wrote: Show quoted text

> FYI, here's the code I'm using to work around this issue at the moment:

There is no issue: liblzf does not have a header, applications using it must add their own (for example, to store the length: The C api exposes this but leaves it up to the user of the library to care for this meta-information). The obvious way to make both interoperable is to prepend the same header that compress-lzf does, which is simply the length of the uncompressed data, UTF-8/UTF-X encoded, or 0 if the data could not be compressed (see the xs code for details). If you wrote C code to illustrate this I would be happy to include it somewhere in the documentation.

Sun Apr 15 02:22:01 2007 The RT System itself - Status changed from 'rejected' to 'open'

Sun Apr 15 02:22:03 2007 MLEHMANN [...] cpan.org - Status changed from 'open' to 'rejected'