public inbox for bzip2-devel@sourceware.org
 help / color / mirror / Atom feed
* Re: libbzip2 - BZ2_bzBuffToBuffDecompress issue
@ 2019-01-01  0:00 Nick Zorn
  2020-06-02 21:46 ` Nick Zorn
  0 siblings, 1 reply; 3+ messages in thread
From: Nick Zorn @ 2019-01-01  0:00 UTC (permalink / raw)
  To: bzip2-devel

What that guy meant to say in the first sentence was "compressed", not
"uncompressed":

"If the size of the buffer allocated to receive the decompressed data
is bigger than the compressed data (which is completely
normal/expected, given you likely do not know how big the decompressed
data will be), one can never receive BZ_OK as a return value -- one
will only ever get BZ_UNEXPECTED_EOF."

Respectfully,
Nick



On Thu, 21 Nov 2019 22:19:46 +0000, Nick V. Zorn wrote:
> Hello bzip2 developers,
>
> I believe I found a potential issue inside the convenience function
> BZ_API(BZ2_bzBuffToBuffDecompress).
>
> If the size of the buffer allocated to receive the decompressed data is
> bigger than the compressed data (which is completely normal/expected,
> given you likely do not know how big the decompressed data will be), one can
> never receive BZ_OK as a return value -- one will only ever get
> BZ_UNEXPECTED_EOF. But more importantly, the destLen value will not be
> updated, making the returned data essentially unusable.
>
> So I made some minor modifications to the code (starting at line 1337 in
> bzlib.c), commented below. I have been using it continuously and without
> error inside an application for over a year.
>
>    output_overflow_or_eof:
>    if (strm.avail_out > 0) {
>        *destLen -= strm.avail_out; // NVZ added this line 08 Nov 2018
>        BZ2_bzDecompressEnd ( &strm );
>        return BZ_OK; // NVZ changed this return value from BZ_UNEXPECTED_EOF on 08 Nov 2018
>    } else {
>       BZ2_bzDecompressEnd ( &strm );
>       return BZ_OUTBUFF_FULL;>    };
>
> Feel free to ignore or shut this down. Otherwise, I hope I may have been
> able to identify an area for potential improvement in a great library. It's
> also nice to see people picking up the torch and continuing to support it.
>
> Thank you.

^ permalink raw reply	[flat|nested] 3+ messages in thread
* libbzip2 - BZ2_bzBuffToBuffDecompress issue
@ 2019-01-01  0:00 Zorn, Nicholas - 0991 - MITLL
  0 siblings, 0 replies; 3+ messages in thread
From: Zorn, Nicholas - 0991 - MITLL @ 2019-01-01  0:00 UTC (permalink / raw)
  To: bzip2-devel

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

Hello bzip2 developers,

I believe I found a potential issue inside the convenience function
BZ_API(BZ2_bzBuffToBuffDecompress).

If the size of the buffer allocated to receive the decompressed data is
bigger than the uncompressed data (which is completely normal/expected,
given you likely do not know how big the decompressed data will be), one can
never receive BZ_OK as a return value – one will only ever get
BZ_UNEXPECTED_EOF. But more importantly, the destLen value will not be
updated, making the returned data essentially unusable.

So I made some minor modifications to the code (starting at line 1337 in
bzlib.c), commented below. I have been using it continuously and without
error inside an application for over a year.

   output_overflow_or_eof:
   if (strm.avail_out > 0) {
       *destLen -= strm.avail_out; // NVZ added this line 08 Nov 2018
       BZ2_bzDecompressEnd ( &strm );
       return BZ_OK; // NVZ changed this return value from BZ_UNEXPECTED_EOF
on 08 Nov 2018
   } else {
      BZ2_bzDecompressEnd ( &strm );
      return BZ_OUTBUFF_FULL;
   };

Feel free to ignore or shut this down. Otherwise, I hope I may have been
able to identify an area for potential improvement in a great library. It’s
also nice to see people picking up the torch and continuing to support it.

Thank you.
-------------------------------------------
Nick V. Zorn
Technical Staff
MIT Lincoln Laboratory
-------------------------------------------


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 7659 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-06-02 21:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-01  0:00 libbzip2 - BZ2_bzBuffToBuffDecompress issue Nick Zorn
2020-06-02 21:46 ` Nick Zorn
  -- strict thread matches above, loose matches on Subject: below --
2019-01-01  0:00 Zorn, Nicholas - 0991 - MITLL

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).