Google rewrote giflib in Rust with Gemini. Here's how they kept it safe to ship.

Google used Gemini to port giflib — about 3,000 lines of C — to Rust, then swapped it into production behind the same API. Five questions worth answering, all from Google’s own Bug Hunters writeup, not secondhand coverage.

1. Why was this port needed, and what problem did it solve?

Memory bugs are roughly 70% of severe vulnerabilities in C and C++.
giflib parses untrusted GIFs, and some services ran it without a sandbox.
Attackers weaponize bugs faster now, so the patch-after-disclosure window keeps shrinking.
Sandboxing the C library works, but it costs tail latency and ongoing ops effort.

fig. 1 — sandbox the library, or remove the bug class from the library

Why giflib first: it is small (~3K LOC), has no SIMD or assembly, and is stable code that rarely changes. That makes it a good pilot, not a typical library.

The payoff arrived unplanned. When CVE-2026-26740 — a heap out-of-bounds write — landed in upstream giflib, Google’s already-migrated production was immune. They did not know about the CVE while working on the rewrite.

2. How was the C code translated to Rust?

Three steps. The translation was one-shot. The fixing was not.

fig. 2 — one-shot translation, then a human-audited fixing loop

One-shot translation worked because the library is small. Google says so explicitly.
The first FFI layer had an “initially very unsound memory management pattern”. The LLM was prompted to fix it, and experts reviewed the result.
Humans audited the unsafe code. They did not write it.

3. How did they keep it a drop-in replacement for existing callers?

The goal was an ABI-compatible replacement, deployed with zero disruption to dependent services.

fig. 3 — replacing C with Rust shrinks unsafe code to the boundary, it does not delete it

Replacing C with Rust does not delete all unsafe. It shrinks it to the boundary.
To match the C API, they built helpers for pointer lifecycle management so Rust ownership rules hold at the interface.
Callers do not change, so the swap is a library replacement — not a code change in every dependent service.

4. How did they prove behavior stayed the same before and after?

The original C code is the oracle. Every check compares Rust against C.

fig. 4 — differential testing: the C implementation defines correct

how sameness was established, and at what scale
check	scale	result
Regression on real GIFs	30M+ files	identical results
Differential fuzzing (C vs Rust, side by side)	200M+ iterations, 6+ days	no logic deviations
Adversarial LLM review	both codebases	hunts subtle behavior gaps tests miss

Beyond tests, Google names two things service owners needed before they would trust the swap:

a transparent validation framework, and
a clearly defined rollback strategy.

The caveat is real: this approach depends on a large real-world corpus and good existing tests. A library without them is a harder case.

5. What bugs did testing find, and how were they addressed?

Two, and only one of them was in the new code:

An edge case in the LZW decoder. A behavior difference between C and Rust. Fixed through the feedback loop — the failure went back to the model for a targeted fix.
A pre-existing out-of-bounds write in the C code. It came from a Google-internal legacy patch to the original source. The Rust rewrite corrected it.

fig. 5 — parity testing found one bug in the port and one in the code being replaced

The second one is the point of the exercise. Parity testing did not just check the port — it exposed a memory bug in the code being replaced.

Costs

Forking upstream means ongoing maintenance when upstream ships changes.
Results on a small, stable library may not carry over to big or fast-moving ones.

Source: Google Bug Hunters — Scaling Memory Safety (Aug 24, 2026). Code: google/giflib-rs.