]> git.ipfire.org Git - thirdparty/haproxy.git/commit
IMPORT: slz: fix the documented worst case size of flush() and finish()
authorAurelien DARRAGON <adarragon@haproxy.com>
Tue, 11 Aug 2026 15:54:06 +0000 (17:54 +0200)
committerAurelien DARRAGON <adarragon@haproxy.com>
Wed, 12 Aug 2026 07:14:07 +0000 (09:14 +0200)
commit71f54efa28d285e066922666bfe7e47879d246bb
treecbfb6f3d7609ba2a7337822aa7bba707e20d7ba2
parentd8a934f903650e9a4f55eac5c6996d5c94025a64
IMPORT: slz: fix the documented worst case size of flush() and finish()

The documented output buffer requirements of the flush() and finish()
functions date back to the 32-bit queue, where at most 7 bits could be
pending. Since the 64-bit queue was introduced (used on x86_64 and armv8),
up to 31 bits may be pending, and the accounting also forgot the EOB that
may have to be emitted before the empty block. As a result a caller
strictly sizing its output buffer from the documentation could be short
by one to two bytes and see the encoder write past the end of its buffer.

Let's update the document worst cases for these functions depending on
what they still have to emit: 31 pending bits + 7 for EOB + 3 for
BFINAL/BTYPE + 7 for EOB or 32 for LEN+NLEN, rounded up to the next
byte (easily forgotten):

  function           claimed   real
  rfc1951_flush()        9      10
  rfc1951_finish()       4       6
  rfc1950_flush()       11      12
  rfc1950_finish()       8      10
  rfc1952_flush()       19      20
  rfc1952_finish()      12      14

Note that all values are at least as large as the previously claimed ones
and that 32-bit systems never consume more than what was claimed, so the
new documented values are valid both for 32 and 64 bits.

Even though this patch only touches comments, it's marked as a bug so
that it is backported where it matters and users have a chance to spot
the new values.

This is libslz upstream commit 1d774851bc0fe2788ef75d9d74057ecd0c54f868
include/import/slz.h
src/slz.c