Google префрли C-библиотека во Rust: проверката била потешка од преводот

Google ја префрли библиотеката giflib од C во Rust со помош на Gemini и ја воведе замената во продукциска обработка на GIF-слики. Според извештајот на InfoQ од 27 септември 2026 година, инженерите Бастијан Керстинг и Макс Хилс провериле повеќе од 30 милиони вистински GIF-датотеки и спровеле 200 милиони итерации на диференцијално fuzzing-тестирање во текот на шест дена. Обемот на таа проверка покажува зошто брзото создавање Rust-код било само почеток на миграцијата.

Објавениот пакет giflib-rs 6.1.3 од 25 август 2026 година е претставен како замена со компатибилен API, наменета за постојни повикувачи на giflib. Неговата документација истовремено наведува дека поврзувањето со C бара unsafe-код за работа со покажувачи. Токму на таа граница човечката ревизија останала неопходна и по преводот со Gemini.

Како Gemini помогнал да се создаде замената

Целта на проектот била да се замени имплементацијата што ги чита и запишува GIF-податоците, без програмите што ја повикуваат библиотеката да мораат да го менуваат својот код. Gemini го создал почетниот Rust-превод од изворниот C-код во еден обид. Потоа инженерите ги усогласувале извезените функции и структурите на податоци со оние што ги очекуваат постојните програми.

Таквата замена има две одделни мерила. Првото е дали C-програмата може да ги најде истите симболи и да размени податоци во очекуваниот распоред; тоа е прашање на бинарниот интерфејс, односно ABI. Второто е дали при ист GIF-влез добива ист декодиран резултат, ист повратен код и соодветна грешка. Превод што се компајлира може да го исполни првото мерило, а сепак да падне на второто кај оштетена или необична датотека.

Затоа улогата на моделот била највидлива во создавањето почетна имплементација и предлагањето поправки кога тестовите ќе откриеле разлика. Одлуката дали поправката навистина го зачувува договорот со повикувачите останала инженерска. Посебно е важно ова кај библиотека што обработува содржина добиена однадвор: токму неочекуваните комбинации на GIF-податоци можат да ги погодат ретко користените патеки во декодерот.

Зошто C-интерфејсот останал најчувствителен

Rust може да ја проверува сопственоста на податоците во својот безбеден код, но C-интерфејсот прима сурови покажувачи без истите гаранции. Кога C ќе предаде адреса, обвивката во Rust мора да утврди дали покажувачот е валиден, кој го поседува објектот и кога тој смее да се ослободи. Ако погрешно го преземе или ослободи, безбедната логика во остатокот од библиотеката не може да ја поправи таа грешка.

Во раните верзии на преводот токму правилата за покажувачите барале доработка. Инженерите ги разгледувале животниот век и сопственоста на објектите што минуваат низ FFI, интерфејсот за повикување код од друг јазик. При затворање GIF-датотека, на пример, обвивката треба да ја поврзе адресата добиена од C со вистинскиот Rust-објект и да избегне повторно ослободување или пристап по ослободувањето. Ова е објаснување на ризикот на границата, а не тврдење дека секоја таква грешка се појавила во објавениот пакет.

Во објавената имплементација unsafe-операциите се ограничени на слојот што обезбедува C API; основната логика не ги користи. Проектот употребува и помошна библиотека за дополнителни ограничувања на тој слој. Таквата поделба ја прави ревизијата поконкретна: инженерот може да ги испита претпоставките за покажувачите таму каде што се претвораат во Rust-објекти, наместо да претпостави дека изборот на јазик сам по себе ја обезбедил целата програма.

Што покажало споредувањето на двата декодера

Диференцијалното тестирање ја користело C-верзијата како споредбена основа: истиот GIF-влез поминува низ старата и новата имплементација, а несовпаѓањето се издвојува за анализа. Со вистински датотеки се проверува однесувањето на материјал што реално го обработуваат системите. Fuzzing-тестирањето, пак, создава многу изменети и необични влезови за да стигне до рабни случаи што обичните примероци ретко ги активираат.

Проверката опфаќала декодирани слики и однесување при грешка, бидејќи библиотеката може да врати погрешен резултат без да падне. При забележана разлика, трагата од извршувањето служела за насочена поправка, а изменетата верзија повторно се споредувала со оригиналот. Дополнително биле користени и прашања до моделот насочени кон можни разлики во двете имплементации. Тој процес открил рабен случај во LZW-декомпресијата и проблем со запишување надвор од дозволената меморија во постара внатрешна C-измена.

Резултатот од голем број совпаѓања е силен доказ за проверените патеки, но не е математички доказ за секој можен GIF-влез. Важен е и изборот што се споредува: еднакви пиксели не значат нужно еднакво постапување со повратни кодови, запис на датотека или неуспешна алокација. Затоа компатибилноста се оценува според целото однесување што можат да го забележат постојните повикувачи.

Објавениот пакет има документирани разлики

Репозиториумот giflib-rs на Google наведува неколку намерни отстапувања од C-имплементацијата. При невалидни димензии, Rust-верзијата поставува код за грешка што оригиналот го остава непроменет. При неуспешно запишување, таа враќа грешка, додека C-верзијата можела да пријави успех. Овие промени ја поправаат обработката на грешки, но повикувач што се потпирал на старото однесување може да забележи разлика.

Разлика постои и при неуспешна алокација на меморија: Rust-верзијата предизвикува panic, а C-верзијата враќа код за грешка. Ова е важна граница на тврдењето дека пакетот е непосредна замена. Истите потписи на функциите овозможуваат интеграција, но не ветуваат идентичен исход во секоја исклучителна состојба. Документираните отстапувања им кажуваат на одржувачите кои стари претпоставки треба да ги разгледаат во своите повикувачи.

За Google, продукциската употреба значи и одржување на посебна Rust-имплементација. Идните исправки во оригиналната C-библиотека нема автоматски да се пресликаат во неа, а секоја промена на C-интерфејсот повторно ги отвора прашањата за ABI, покажувачите и тестовите. Придобивката од побезбедна основна логика затоа зависи и од тоа дали споредбената проверка и ревизијата на FFI ќе продолжат со развојот на пакетот.