nordisk/znippy-zoomies

zstd-sys-rs — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: Rust bindings to a statically-linked, vendored zstd v1.5.7, wrapped in a small safe zero-copy (de)compress API.
• Does: Vendors the full zstd C library (zstd/lib/**) and compiles+links it statically at build time via cc, generating FFI bindings with bindgen into OUT_DIR (include!d in lib.rs). The safe module exposes a safe surface: compress, compress_bound, decompress, decompress_into, frame_content_size, a reusable Decompressor, plus Error/Result.
• Key deps: build — cc, bindgen, glob (compile vendored C + gen bindings); runtime — libc. No intra-workspace deps. This is the workspace's one FFI/C-dependent crate.
• Shape: lib only, tiny Rust surface (~200 LoC: lib.rs 10, safe.rs 191) over a large vendored C tree. doctest = false. BSD-3-Clause (zstd's license); include list packages the C sources for cargo publish.
• Observed role in the workspace: Provides zstd (de)compression to osm-katana (its only in-workspace dependent seen). Named -rs because it was moved here from a deprecated standalone *-rs repo.

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: