Skip to content

Commit 9a15ae9

Browse files
authored
Merge pull request #68 from trifectatechfoundation/blogpost-zlib-stable-api
blog post on zlib 0.6
2 parents 7be1a27 + ecb3c2c commit 9a15ae9

File tree

4 files changed

+60
-0
lines changed

4 files changed

+60
-0
lines changed

content/blog/zlib-rs stable API.md

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
+++
2+
title = "zlib-rs: a stable API and 30M downloads"
3+
slug = "zlib-rs-stable-api"
4+
authors = ["Folkert de Vries"]
5+
date = "2026-01-27"
6+
7+
[taxonomies]
8+
tags = ["zlib-rs", "data compression"]
9+
10+
+++
11+
12+
Since the first release in April 2024, zlib-rs has come a long way. It has seen major adoption over the last year, and, we're proud to say, is now feature complete.
13+
We've released zlib-rs 0.6, the first version with [a stable and complete API](https://docs.rs/zlib-rs/0.6.0/zlib_rs/).
14+
15+
<!-- more -->
16+
17+
With this milestone, we now fully deliver on the promise of our [Data compression initiative](/initiatives/data-compression): real alternatives to C/C++ counterparts that reduce attack surface through memory safety and provide on-par performance.
18+
19+
Features and promises are nice, but seeing adoption grow is the cherry on the cake: zlib-rs recently crossed 30M downloads, 25M+ in the last year, and is on track to become the default implementation in `flate2`, which is expected to further boost usage.
20+
21+
This blog post is a quick round-up of the latest release, 0.6. The full release notes are [here](https://github.com/trifectatechfoundation/zlib-rs/releases/tag/v0.6.0).
22+
23+
## Stable API
24+
25+
The `zlib-rs` crate now has a stable API. It hides away most of the internals, but exposes enough for `flate2` and `rustls`. Generally we recommend to use `zlib-rs` via `flate2` in applications, but for low-level libraries using `zlib-rs` directly is now an option.
26+
27+
Additionally `flate2` now uses the `zlib-rs` CRC32 checksum implementation when `zlib-rs` is used. Our implementation is faster, and it saves a dependency.
28+
29+
## C-compatible API
30+
31+
The `libz-rs-sys` crate is a C-compatible API built on top of `zlib-rs`. It can be compiled into a drop-in compatible C library.
32+
33+
### ABI changes
34+
35+
All exported functions now use `extern "C"` instead of `extern "C-unwind"`.
36+
37+
This is a change we've wanted to make for a while, but held off on because we had rust crates using `libz-rs-sys`. Now that they instead use `zlib-rs` directly, we can focus more on C users in the `libz-rs-sys` crate.
38+
39+
Normally, when rust functions panic, they start unwinding the stack. That is only valid when the caller anticipates that the callee might unwind. For rust functions this case is handled, but when exporting a function, the caller is likely not written in rust, and does not support stack unwinding.
40+
41+
If the callee does unwind into an unsuspecting caller, behavior is undefined. Although `libz-rs-sys` should not panic, causing UB when we somehow do is a massive footgun. So now we use `extern "C"`, which will instead abort the program at the FFI boundary.
42+
43+
### Support for `gz*` functions
44+
45+
We've added functions like `gzread`, `gzwrite` and many others to the `libz-rs-sys` API. These were already available in `libz-rs-sys-cdylib`, and have now been promoted. They are still behind the `gz` feature, so enable that if you need these functions. Most of the `gz*` functions were implemented by [@brian-pane](https://github.com/brian-pane).
46+
47+
In addition, we've implemented several other missing functions (like `inflateBack`), so that we're now fully compatible with the zlib and zlib-ng public API.
48+
49+
## Thank yous
50+
51+
For completing this final milestone we thank all the contributors, specifically [@brian-pane](https://github.com/brian-pane), and the [Sovereign Tech Fund](https://www.sovereign.tech/) for investing in the API stabilization.
52+
53+
## What's next
54+
55+
Although the public API is now complete, a project like this is never truly done. There are always new optimization ideas to try, versions to update, and obscure edge cases to support.
56+
57+
The biggest remaining items is that technically the API is only complete when using nightly rust. The `gzprintf` and `gzvprintf` functions are c-variadic, and c-variadic function definitions are currently unstable. I hope to stabilize [`#[feature(c_variadic)]`](https://github.com/rust-lang/rust/issues/44930) in the next ~6 months.

content/initiatives/data-compression.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,7 @@ supporters = [
3131
]
3232

3333
blogposts = [
34+
"zlib-rs stable API",
3435
"Emulating avx-512 intrinsics in Miri",
3536
"bzip2 crate switches from C to 100% rust",
3637
"SIMD in zlib-rs (part 2): compare256",

content/news.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,7 @@ template = "news.html"
55

66
[extra]
77
blogposts = [
8+
"zlib-rs stable API",
89
"Video: sudo-rs and beyond (Ubuntu Summit 25.10)",
910
"Calling for memory safety incentives in EU cybersecurity policies",
1011
"Emulating avx-512 intrinsics in Miri",

content/projects/zlib-rs.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,7 @@ supporters = [
2828
]
2929

3030
blogposts = [
31+
"zlib-rs stable API",
3132
"Emulating avx-512 intrinsics in Miri",
3233
"SIMD in zlib-rs (part 2): compare256",
3334
"SIMD in zlib-rs (part 1): Autovectorization and target features",

0 commit comments

Comments
 (0)