Краткий ответ

Результат можно считать значением типа только тогда, когда нулевой битовый шаблон является допустимым представлением этого типа и сохраняет все его инварианты. Одного совпадения размера, выравнивания или успешного выделения памяти недостаточно: например, нулевые байты не образуют корректное значение для NonZeroU32.

Если тип не допускает нулевое представление, создание такого значения через mem::zeroed или последующее объявление нулевых байтов инициализированным значением приводит к неопределённому поведению. MaybeUninit::zeroed позволяет подготовить байты, но не делает их автоматически валидным значением типа.

Исторический контекст

В системном программировании и C-интерфейсах часто используется обнуление памяти: например, C-структуру заполняют нулевыми байтами как начальное состояние. Такой подход удобен на уровне байтов, но Rust дополнительно проверяет концепцию валидного значения типа.

Это разделение необходимо, потому что некоторые Rust-типы кодируют инварианты в самом представлении. Нулевой адрес, недопустимое значение перечисления или нулевое значение типа NonZeroU32 могут быть запрещены независимо от того, что память физически доступна.

Постановка проблемы

Небезопасный код может получить память, заполненную нулями, и ошибочно считать, что в ней находится произвольный T. Это опасно для ссылок, указателей с особыми гарантиями, NonZero*, некоторых перечислений, типов с Drop и структур, чьи поля имеют собственные ограничения.

Последствия возникают уже в момент формирования недопустимого значения, а не только при последующем разыменовании или чтении поля. Поэтому проверка «буфер достаточно велик» не заменяет проверку валидности битового представления.

Подробное решение

mem::zeroed::<T>() создаёт значение T, чьи байты установлены в ноль. Операция требует unsafe, потому что вызывающий код обязан доказать: нулевой шаблон допустим для T, включая все его поля и вложенные типы.

use std::mem::{self, MaybeUninit};
use std::num::NonZeroU32;

fn main() {
    let number: u32 = unsafe { mem::zeroed() };
    let bytes: MaybeUninit<NonZeroU32> = MaybeUninit::zeroed();

    let _ = number;
    let _ = bytes;
    // assume_init для bytes был бы некорректен:
    // ноль не является допустимым NonZeroU32.
}

Для u32 нулевое представление допустимо. Для NonZeroU32 оно недопустимо по определению типа. Аналогично, нельзя без доказательства обнулять типы, для которых отдельные значения зарезервированы или должны удовлетворять дополнительным условиям.

MaybeUninit<T> отделяет работу с неинициализированными или временно неподтверждёнными байтами от готового значения T. Но вызов assume_init требует отдельного доказательства, что содержимое уже образует валидный T; само наличие MaybeUninit::zeroed такого доказательства не даёт.

В FFI безопаснее разделять проводной тип и доменный Rust-тип. Проводная repr(C)-структура может содержать простые целочисленные поля, соответствующие формату C. После получения данных Rust проверяет диапазоны и специальные значения, а затем создаёт типы с более строгими инвариантами.

Обнуление допустимо применять только после анализа всего типа: валидности каждого поля, требований к перечислениям, указателям, выравниванию и возможных инвариантов Drop. Даже если C-код гарантирует, что его нулевая структура логически означает «пусто», это не означает, что такой шаблон является валидным представлением произвольной Rust-структуры.

Ситуация из практики

C-библиотека возвращает запись, которую принято получать в виде полностью нулевого блока. В Rust-разработчик описал эту запись структурой, содержащей NonZeroU32 для идентификатора, и попытался создать её обнулением памяти.

Рассматривались два варианта. Первый — оставить Rust-структуру и использовать mem::zeroed: это коротко, но требует ложного предположения о валидности нулевого идентификатора. Второй — описать FFI-запись отдельной repr(C)-структурой с u32, принять нулевое значение как часть протокола и преобразовать его после проверки.

Выбран второй вариант. Он явно отделяет формат C от инвариантного доменного типа: нулевой идентификатор обрабатывается как специальное состояние или ошибка, а NonZeroU32 создаётся только через проверяющий конструктор. Это увеличивает количество кода, зато исключает неопределённое поведение и делает контракт протокола видимым в обёртке.

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

Достаточно ли совпадения размера и выравнивания, чтобы нулевой буфер был значением типа?

Нет. Размер и выравнивание описывают размещение объекта, но не множество допустимых битовых представлений. Тип может занимать четыре байта и при этом запрещать часть значений, как NonZeroU32 запрещает ноль.

Эквивалентно ли побайтовое обнуление вызову Default::default?

Нет. Default создаёт значение по семантическим правилам реализации типа, а обнуление задаёт конкретный битовый шаблон. Для пользовательского типа значение по умолчанию может быть ненулевым, а некоторые типы вообще не реализуют Default или требуют проверки внешних условий.

Становится ли любое содержимое безопасным после помещения в MaybeUninit<T>?

Нет. MaybeUninit<T> разрешает временно хранить байты, которые ещё не являются T, но не отменяет требования к моменту инициализации. Перед assume_init нужно доказать валидность всего представления; иначе неопределённое поведение возникает при извлечении значения, даже если байты были записаны без выхода за границы.