xz_dec_run(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’œ xz_dec_run(9) β€” the one that actually runs the XZ decoder πŸ’œ

okay so bestie, welcome to xz_dec_run(9) from the Kernel API Manual β€” yes the kernel has a whole manpage vibe and honestly? iconic. this is the function that literally runs the XZ decoder. let's get into it 🫢


✨ SYNOPSIS ✨

enum xz_ret xz_dec_run (struct xz_dec *s , struct xz_buf *b );

like, that's it. two args. slay.


πŸŽ€ ARGUMENTS πŸŽ€

  • s β€” the decoder state, and no you can't just make one up out of thin air, it has to be allocated using xz_dec_init. main character energy only πŸ’…
  • b β€” the input and output buffers. that's the whole vibe, in and out.

πŸ¦‹ DESCRIPTION πŸ¦‹

so the possible return values depend on build options and operation mode β€” like, it's giving ✨situational✨. for the details you gotta go see enum xz_ret. iykyk 🌈

⚠️ okay this part is important, don't skip it ⚠️

note that if an error occurs in single-call mode (aka the return value is not XZ_STREAM_END), then b->in_pos and b->out_pos are not modified, and the contents of the output buffer from b->out[b->out_pos] onward are undefined. 😭 like literally undefined-undefined, not "probably fine"-undefined.

and bestie, this is true even after XZ_BUF_ERROR β€” because with some filter chains, there may be a second pass over the output buffer, and that pass cannot be properly done if the output buffer is truncated. so no, you cannot hand the single-call decoder a too-small buffer and then expect to get that amount of valid data from the beginning of the stream. that's not how any of this works, ngl πŸ’€

translation: if you don't want to uncompress the whole entire stream, you must use the multi-call decoder. periodt. πŸ”₯


🌸 SEE ALSO 🌸

like a whole little friend group of functions, obsessed πŸ’–


and that's the page!! this one lives over in ./include/linux and it's dated October 2026 β€” so go forth and decode responsibly, bestie. mwah πŸ’‹βœ¨πŸ§š

πŸ“¦ where this page comes from