LZ4_compress_HC_continue(9)

📦 version 7.3.1, in nixpkgs unstable

💅 LZ4_compress_HC_continue(9) — the kernel API manual, but make it make sense 🎀

okay bestie, so this is a section 9 kernel API page (that's the (9) — kernel-land, not your regular user commands, iykyk). Buckle up, this one's actually iconic once it clicks. 🦋

✨ NAME ✨

LZ4_compress_HC_continue — compresses src using data from previously compressed blocks as a dictionary, and it does it with the HC algorithm (that's High Compression, the fancy one 💅).

🌸 SYNOPSIS 🌸

int LZ4_compress_HC_continue (LZ4_streamHC_t *streamHCPtr , const char
*src , char *dst , int srcSize , int maxDstSize );

literally the whole vibe in one line, no cap.

🎀 ARGUMENTS 🎀

  • streamHCPtr — a pointer to the previous LZ4_streamHC_t structure. this is your little state baby, it remembers stuff between blocks 🫶
  • src — the source address of the original data. the raw material, the moment before compression ✨
  • dst — the output buffer address for the compressed data, and heads up: it must be already allocated. you can't just hand over a vibe and hope 🫠
  • srcSize — the size of the input data. the max supported value is LZ4_MAX_INPUT_SIZE, so don't go overboard 💀
  • maxDstSize — the full or partial size of buffer dest, which must already be allocated too. (yes, the manpage says dest here while the param is dst — i did not write this, i am merely the messenger 🙈)

🧚 DESCRIPTION 🧚

okay so the way this works: these functions compress data in successive blocks of any size, using previous blocks as a dictionary. it's giving "build on what came before" main character energy. 👑

one key assumption tho — previous blocks (up to 64 KB) remain read-accessible while you're compressing the next blocks. that's the whole deal, bestie.

there is an exception for ring buffers, which can be smaller than 64 KB. 💫 the ring buffers scenario is automatically detected and handled by LZ4_compress_HC_continue, so you don't gotta do a thing. slay.

before you even start compressing, the state must be properly initialized, using LZ4_resetStreamHC. then a first "fictional block" can be designated as the initial dictionary, using LZ4_loadDictHC (this part is Optional — no pressure 🌈).

then, use LZ4_compress_HC_continue to compress each successive block. and this is the important bit: previous memory blocks (including the initial dictionary when present) must remain accessible and unmodified during compression. don't be out here editing your own history, it will not eat 😭

LZ4_compressBound, to ensure operation success. 🔥 (yes that's how the original rolls, we keeping it)

now — if, for any reason, previous data blocks can't be preserved unmodified in memory during the next compression block, you must save it to a safer memory space, using LZ4_saveDictHC. the return value of LZ4_saveDictHC is the size of the dictionary effectively saved into 'safeBuffer'. note that: effectively saved. it's not a promise, it's a receipt 🧾✨

⭐ RETURN ⭐

the number of bytes written into buffer 'dst' — or 0 if compression fails. that's it. zero means sad times, positive number means we ate 💅

🦋 SEE ALSO 🦋

the kernel file ./include/linux/lz4.h, plus the whole extended lz4 family reunion:

like, the entire friend group. go read them too, they're all valid 💜

💖 and that's the page!! source lives in ./include/linux, version stamped October 2026, and it's filed under Kernel API Manual — so if you ever need to cite your sources, that's where she lives. mwah, go compress something responsibly, bestie 🫶🌸
📦 where this page comes from