Google engineers described a pilot in the Bug Hunters blog in which the Gemini model rewrote the classic C library giflib for decoding GIFs, about three thousand lines in size, into a memory-safe Rust version. The result is designed as an ABI-compatible drop-in replacement for production infrastructure and passed a rigorous equivalence check: bit-for-bit match with the original on a corpus of tens of millions of real GIFs and multi-day parallel fuzzing of both versions without a single logical discrepancy. Shortly after the rollout began, CVE-2026-26740, a heap buffer overflow, was publicly disclosed in the original giflib 5.2.2 — and Google systems that had already migrated to the Rust version were immune to it.

image

What happened

Google engineers Bastian Kersting and Max Hils described a pilot to migrate giflib, Eric Raymond's library for decoding GIFs, from C to Rust using Gemini; the target result is an ABI-compatible drop-in replacement that can be placed in production infrastructure without changing the calling code. The work did not come down to a single generation: it was followed by iterative fixing of the FFI boundary, with all unsafe code finally reviewed by experts. Validation relied on three layers: a regression run on more than 30 million real GIFs, where the output of the Rust version matched the original bit-for-bit; parallel differential fuzzing of the C and Rust versions — more than 200 million iterations over six and a half days with no logical discrepancies; and LLM-adversarial review, which additionally found an edge case in the LZW decoder and an out-of-bounds write inherited from an internal Google patch. Compiler boundary checks did not incur a price penalty: performance remained neutral, tail latency of decoding decreased, and the sandbox around the library was removed. The rollout was phased, with a pre-prepared rollback plan.

Context

The motivation for the migration is quantitative: approximately 70% of vulnerabilities in C/C++ code belong to the class of memory safety issues. Historically, owners of such code had two paths — eternal patching of old libraries or manual rewriting by humans; as an example of the second path, the material mentions the zlib-rs project from the Trifecta Tech Foundation. giflib turned out to be a successful first candidate due to the structure of the task: it is a compact, strictly specified decoder of the format, for which a ready-made equivalence oracle exists in the form of bit-for-bit comparison of outputs and a huge natural corpus of input data. It is precisely the requirement of equivalence that sets the price of the method: the behavior of the replacement must match the original, which is impossible without large datasets of real data, differential testing, and intensive fuzzing, and the team's trust in the generated code is earned by the volume of such validation, not by faith in the model.

Why this matters for the industry

For the industry, this is a reproducible pipeline for structural sanitization of dependencies: one-step LLM rewriting, iterative fixing of the FFI boundary with expert review of unsafe code, differential fuzzing plus adversarial LLM analysis, and phased deployment with a rollback plan — the scheme can be transferred to other libraries. The CVE-2026-26740 case became the first real-world demonstration of the main thesis: such a migration eliminates as a class not yet disclosed zero-day vulnerabilities in dependencies, not by patching one CVE at a time, meaning the migration becomes insurance against future vulnerabilities, not just a one-time expense. A pragmatic conclusion for product builders: code generation through models is being commoditized, and value is shifting to the wrapper of proven equivalence — regression on real data, parallel fuzzing, adversarial review, and CI integration of such checks. Priorities are also clear now: the first candidates for migration appear to be decoders and parsers that intensively process untrusted input.

Why this matters for users

The methodology is reusable today without waiting for a ready-made product. For your small C dependency, you can build a regression corpus of real inputs, compare the behavior of the old and new versions bit-for-bit, run differential fuzzing of two variants in parallel, and add LLM-adversarial review — the last technique is applicable even to code that no one is going to rewrite and can find hidden defects in an existing project. The material honestly calibrates expectations: trust in generated code is earned by validation, and quick wins are not guaranteed. A practical argument against the thesis that "safe means slow" has also been obtained: compiler boundary checks did not reduce performance, and the tail latency of decoding even decreased. The starting action for a team is to map its C/C++ dependencies and choose candidates with a well-specified format and a large flow of untrusted input.

What is still unknown / limitations

This is still an n=1 case: about 3000 lines of a compact, strictly specified decoder with a ready-made equivalence oracle and a huge natural corpus of inputs. It is unknown whether the pipeline scales to larger libraries, less specified interfaces, or domains where bit-for-bit equivalence is unachievable; the answer should be given by independent replications with metrics on code size and domain type. There is no ready-made turnkey product: access to Gemini, a corpus of real input data, and fuzzing infrastructure are needed. The C/Rust boundary (FFI) remains an unsafe zone even after a successful migration, so the method does not work without expert review of unsafe code. Finally, the conclusion encountered in discussions that LLM rewriting "has stopped being an experiment" is premature: the barrier to migrations has noticeably decreased, but has not disappeared.

Sources

Author

Look at AI, editorial team