Атрибут #[repr(packed)] возникает из требований системного программирования, где компоновка памяти должна соответствовать внешним спецификациям — например, аппаратным регистрам или сетевым протоколам — путем устранения байтов заполнения между полями. Хотя Rust обычно гарантирует, что ссылки выровнены в соответствии с требованиями типа, на который они указывают, упакованные структуры заставляют поля располагаться по последовательным смещениями байтов независимо от выравнивания, что потенциально ставит u32 по адресу, не кратному четырем. Попытка создать ссылку (& или &mut) на такое невыравненное поле является немедленным неопределенным поведением, поскольку компилятор и LLVM предполагают, что выровненные адреса используются для оптимизаций, таких как векторизация или атомарные операции. Чтобы безопасно получить доступ к данным, необходимо полностью избежать создания промежуточных ссылок, вместо этого используя макросы addr_of! и addr_of_mut! для получения сырьевых указателей напрямую, а затем применяя ptr::read_unaligned или ptr::write_unaligned, чтобы копировать данные без предположений о выравнивании.
use std::ptr::{addr_of, read_unaligned}; #[repr(packed)] struct Packet { flags: u8, timestamp: u64, // Потенциально на смещении 1, невыравненное } fn get_timestamp(p: &Packet) -> u64 { // УБ: &p.timestamp создаст невыровненную ссылку let raw_ptr = addr_of!(p.timestamp); unsafe { read_unaligned(raw_ptr) } }
При разработке парсера без копирования для бинарного финансового протокола (FIX) команде требовалась структура, точно соответствующая формату проводов: u8 тип сообщения, за которым немедленно следует u64 временная метка без заполнения. Начальная реализация использовала #[repr(packed)] с прямым доступом к полям, что приводило к периодическим сбоям сегментации на архитектурах ARM, где невыравненный доступ вызывает исключения в ядро.
Было оценено несколько решений. Во-первых, ручная реконструкция побайтово с использованием сдвигов и операций OR: это устраняло проблемы с выравниванием, но вводило значительные накладные расходы на ЦП на пакет и ошибкоопасную логику битовых манипуляций, что усложняло аудит. Во-вторых, использование #[repr(C)] с явными полями заполнения для принудительного выравнивания: это сохраняло безопасность, но нарушало совместимость протокола, изменяя смещения байтов последующих полей, что требовало дорогих копий памяти для перераспределения данных перед передачей. В-третьих, сохранение #[repr(packed)], но доступ к полям только через сырьевые указатели с невыровненными чтениями: это сохраняло точную компоновку памяти, избегая неопределенного поведения, никогда не создавая выровненные ссылки на поле временной метки.
Команда выбрала третий подход, реализовав метод получения, который использовал addr_of!(self.timestamp), а затем ptr::read_unaligned для возврата значения временной метки. Это устранило сбои на ARM и x86_64, сохраняя архитектуру без копирования, снизив задержку на 40% по сравнению с подходом побайтовой реконструкции.
Почему создание ссылки на невыровненное поле является неопределенным поведением даже на архитектурах, поддерживающих невыравненный доступ?
Хотя процессоры x86_64 допускают невыровненные загрузки на уровне аппаратного обеспечения, правила неопределенного поведения Rust строже, чем возможности аппаратного обеспечения, чтобы обеспечить агрессивные оптимизации. Когда компилятор видит &u32, он предполагает, что адрес выровнен по четырем байтам, что позволяет ему генерировать инструкции SIMD, оптимизировать последующие проверки на выравнивание или переупорядочивать операции с памятью. Нарушение этого предположения — даже на прощающем аппаратном обеспечении — позволяет компилятору неправильно скомпилировать код, что потенциально вызывает сбои или молчаливую порчу данных на будущих версиях компилятора или других архитектурах.
Как макрос addr_of! семантически отличается от оператора &, когда применяется к полям упакованной структуры?
Оператор & концептуально сначала создает ссылку, а затем преобразует ее в сырьевой указатель, если она назначается одному, тем самым сразу же вызывая проверку действительности выравнивания. В отличие от этого, addr_of! — это встроенный макрос, который вычисляет адрес непосредственно без создания промежуточной ссылки, полностью обходя требование выравнивания. Это различие имеет решающее значение, поскольку addr_of! возвращает *const T, который может быть невыровненным, тогда как &field будет УБ, если поле невыровненное, даже если немедленно приведено к указателю.
Почему реализация Drop для упакованной структуры, содержащей поля, не имеющие копии, вызывает проблемы, и как можно безопасно реализовать пользовательское уничтожение?
Метод Drop::drop получает &mut self, который выровнен (сама структура поддерживает общее выравнивание), но уничтожение отдельных полей требует вызова их деструкторов с &mut Field. Если поле имеет более высокое выравнивание, чем начало структуры, и, следовательно, является невыровненным, создание &mut Field для вызова Drop является неопределенным поведением. Чтобы безопасно уничтожить такие структуры, необходимо обернуть поля, не имеющие копии, в ManuallyDrop, затем в пользовательской реализации Drop использовать ptr::read_unaligned или ptr::drop_in_place на сырьевых указателях, полученных с помощью addr_of_mut!, гарантируя, что деструктор запускается без создания выровненной ссылки на невыровненное поле.