Раскройте архитектурную гарантию, которую предоставляет **#[repr(transparent)]** для новых оберток newtype, совместимых с **ABI**, и укажите неопределенное поведение, возникающее, когда структуры **repr(Rust)** ошибочно используются в контекстах **FFI**, ожидающих точное представление памяти внутреннего типа.

Ответ на вопрос

История вопроса:

До RFC 1758 в Rust отсутствовал механизм нулевых затрат для новых типов в FFI. Разработчики полагались на #[repr(C)], который накладывает детерминированное представление, но может вводить ненужный отступ, или на #[repr(Rust)], который позволяет агрессивные оптимизации компилятора, такие как переупорядочение полей и использование ниш. Это создало основную дилемму: обеспечение типовой безопасности через обертки против гарантии стабильности ABI для вызовов чуждых функций. #[repr(transparent)] был введен специально для разрешения этого противоречия, обещая, что структура, содержащая ровно одно ненулевое поле, обладает идентичным представлением памяти, выравниванием и конвенцией вызова, как и это поле.

Проблема:

Когда #[repr(Rust)] новый тип передается по ссылке или значению чуждой функции, ожидающей сырой внутренний тип (например, дескриптор u32), компилятор остается свободным в переупорядочении полей обертки или применении нишевых оптимизаций. Поскольку #[repr(Rust)] не предоставляет никаких гарантий стабильности, обертка может получить другой размер, действительность битовой карты или отступ, чем внутренний тип. Это приводит к тому, что чуждый C код потенциально считывает несоответствующую память, интерпретирует недействительные битовые шаблоны как действительные указатели или получает мусорные данные, что приводит к немедленному неопределенному поведению и катастрофическому повреждению памяти на границе.

Решение:

#[repr(transparent)] указывает компилятору обеспечить, чтобы обертка и ее единственное ненулевое поле имели идентичный размер, выравнивание и ABI, эффективно делая обертку абстракцией только на этапе компиляции. Компилятор статически проверяет, что ровно одно поле имеет ненулевой размер (разрешая дополнительные поля PhantomData или типа единицы). Это позволяет безопасно преобразовывать обертку в внутренний тип или передавать напрямую через границы FFI без накладных расходов на преобразование, как показано ниже:

#[repr(transparent)]
pub struct SocketFd(i32);

extern "C" {
    fn close_socket(fd: i32);
}

pub fn close(sock: SocketFd) {
    // Безопасно: SocketFd имеет идентичный ABI к i32
    unsafe { close_socket(sock.0); }
}

Жизненная ситуация

Разработчик интегрирует приложение Rust с API сокетов netlink ядра Linux, которое общается через сырые целочисленные дескрипторы файлов. Чтобы избежать случайного смешивания типов сокетов, они определяют struct NetlinkSocket(i32) как новый тип. Изначально помеченный как #[repr(Rust)], они передают ссылки на NetlinkSocket в extern "C" обратный вызов, ожидающий указателя на i32. В ходе локальной разработки это выглядит как работающая схема, но в релизных сборках с использованием LTO (оптимизация времени линковки) компилятор применяет агрессивную нишевую оптимизацию к NetlinkSocket, основательно изменяя его представление в памяти. Модуль ядра C затем получает поврежденное значение указателя, вызывая критическую панику ядра.

Были оценены три различных решения. Во-первых, рассматривался вариант с #[repr(C)], чтобы обеспечить стабильное, детерминированное представление. Хотя это гарантировало безопасность памяти, оно отключало полезные нишевые оптимизации и потенциально вводило байты отступа, ненужным образом увеличивая размер структуры и усложняя интерфейс API для исключительно внутреннего использования в Rust.

Во-вторых, было попытано вручную разыменовывать внутреннее поле (socket.0) на каждом месте вызова FFI. Этот подход избегал предположений о представлении, но оказался крайне подвержен ошибкам и многословным, фактически разрушая барьер абстракции и позволяя неразмеченным, не типизированным целым числам бесконтрольно распространяться по всему коду.

В-третьих, к NetlinkSocket было применено #[repr(transparent)]. Эта гарантия обеспечила эквивалентность ABI с i32 при сохранении различия типов внутри Rust, позволяя структуре безопасно передаваться в C без ручной распаковки или логики преобразования.

Инженерная команда в конечном итоге приняла #[repr(transparent)], что полностью устранило паники ядра, сохраняя при этом абстракцию с нулевыми затратами. Обертка теперь служит строгой защитой времени компиляции внутри Rust, оставаясь полностью невидимой и совместимой с ABI C.

Что часто упускают кандидаты

Почему #[repr(transparent)] явно запрещает единственному ненулевому полю быть нулезначным типом, и как это ограничение предотвращает неопределенное поведение в FFI при передаче по значению?

#[repr(transparent)] гарантирует, что обертка идентична своему внутреннему типу по ABI. Нулевой тип (ZST) имеет размер ноль и выравнивание 1. Если бы обертке было разрешено оборачивать исключительно ZST, конечная структура также была бы нулевого размера; однако C не имеет нулевых типов и его конвенции вызова обычно ожидают хотя бы один байт данных для семантики «передачи по значению». Передача ZST по значению через FFI представляет собой неопределенное поведение, поскольку C не может представлять или правильно обрабатывать нулевые значения. Это ограничение гарантирует, что обертка всегда сохраняет тот же ненулевой размер и выравнивание, что и ее подлежащие поля, сохраняя хорошо определенный ABI, совместимый с ожиданиями C.

Можно ли применять #[repr(transparent)] к перечислениям и какие ограничения регулируют видимость дискриминанта через границы FFI?

Да, #[repr(transparent)] может применяться к перечислениям, содержащим ровно один вариант, который также должен содержать ровно одно ненулевое поле. Перечисление также должно указывать явное примитивное представление (например, #[repr(u8)]), чтобы определить тип дискриминанта. Тем не менее, #[repr(transparent)] гарантирует, что окончательная структура идентична нелезуному полю, фактически устраняя дискриминант из ABI. Следовательно, передача такого перечисления в C как подлежащего типа безопасна, но попытка получить доступ или интерпретировать значение дискриминанта из C приводит к неопределенному поведению. Кандидаты часто неправильно понимают, что дискриминант физически отсутствует в представлении, а не просто скрыт или недоступен.

Как наличие PhantomData<T> в качестве дополнительного поля в структуре #[repr(transparent)] влияет на вариацию и проверку на сброс, не влияя на ABI?

PhantomData<T> явно разрешен в качестве вторичного поля в структурах #[repr(transparent)], поскольку он имеет нулевой размер с выравниванием 1. Хотя он не изменяет размер, выравнивание или ABI обертки (поскольку #[repr(transparent)] учитывает только одно ненулевое поле для представления), он критически информирует компилятор о структурной связи с параметром типа T. Это влияет на вариацию: например, структура Wrapper<T>(*const T, PhantomData<fn(T)>) будет контравариантной по отношению к T благодаря маркеру PhantomData. Кроме того, это позволяет анализу Drop Check (dropck) распознать, что структура может концептуально владеть данными типа T, предотвращая несоответствия, когда T имеет не-'static продолжительности. Кандидаты часто ошибочно полагают, что PhantomData влияет на представление памяти или игнорируют его важнейшую роль в поддержании инвариантов продолжительности и владения для общих оберток FFI.