Skip Menu |

This queue is for tickets about the IO-Compress-Brotli CPAN distribution.

Report information
The Basics
Id: 129480
Status: resolved
Priority: 0/
Queue: IO-Compress-Brotli

People
Owner: Nobody in particular
Requestors: tlhackque [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.004_002



Subject: unbro should not require maximum buffer size
Date: Tue, 7 May 2019 08:22:37 -0400
To: bug-IO-Compress-Brotli [...] rt.cpan.org
From: tlhackque <tlhackque [...] yahoo.com>
A block created with $compressed = bro( $data ) can't be uncompressed with unbro without some a-priori knowledge of the output block size.  In the general case, this isn't available - and is very unPerlish. Assuming that I trust that the output won't cause unacceptably large output [memory exhaustion] (e.g. because I put the data into a database), this constraint is unnecessarily inconvenient. It turns out that the OO decompressor is more reasonable, as this seems to be a functional replacement for unbro( $compressed, <unlimited>): sub debro {     my $bro = IO::Uncompress::Brotli->create;     return $bro->decompress( $_[0] ); } The XS code for 'decompress' seems to decompress the stream in blocks of up to about 10MB, appending to a Perl string if the decompressed data requires more than one such block. However, this requires the user to create a one-shot object. Please make the $maximum_decoded_size argument optional.  If not present (or undef), unbro should allocate whatever space is necessary - the XS version of debro(). This would make bro/unbro drop-in replacements for Compress::Zlib's compress & uncompress... If $maximum_decoded_size is present and defined, it's reasonable for it to act as it does today - die on error. Thanks. Also, note that the references to https://www.ietf.org/id/draft-alakuijala-brotli-08.txt in the POD need to be updated: (a) The link doesn't work (and there are several later drafts) - this does https://tools.ietf.org/html/draft-alakuijala-brotli-08 (b) More importantly, the drafts have been superseded by RFC7932  https://tools.ietf.org/html/rfc7932
Should be fixed in development release 0.004_002.