До версии Rust 1.36 разработчики полагались на std::mem::uninitialized для выделения памяти в стеке под значения, которые будут инициализированы позже. Эта функция была fundamentally unsound, потому что сообщала компилятору, что валидный T существует по этому адресу в памяти, хотя биты были случайными. Для типов с инвариантами безопасности — такими как bool, char или ссылки — это приводило к немедленному неопределенному поведению, поскольку компилятор оптимизировал код, полагаясь на предположение о валидности значения (например, bool, равный 0 или 1). RFC 1892 представила MaybeUninit<T> как абстракцию, похожую на union, для явного обозначения памяти, которая еще не содержит валидный T, тем самым закрывая эту дыру в безопасности.
Основная проблема заключается в том, что LLVM трактует неинициализированную память как undef или poison, в сочетании с автоматической генерацией drop glue в Rust. Когда компилятор считает, что переменная типа T жива, он может генерировать вызовы деструкторов или оптимизации ниши. Если T — это bool, неинициализированный байт может содержать значение 2, что нарушает инвариант валидности бит. Чтение этого во время проверки дропа или инспекции дискриминатора будет являться неопределенным поведением. Кроме того, если инициализация не удалась на каком-то этапе массива, glue для дропа типа массива будет пытаться освободить все элементы, интерпретируя неинициализированные байты стека как указатели, что вызовет ошибки use-after-free или double-free.
MaybeUninit<T> действует как типизированный контейнер, который может или не может содержать валидный T. Он предотвращает предположения компилятора об инициализации, тем самым отключая генерацию glue для дропа и оптимизации с недопустимым шаблоном бит. Программист должен вручную отслеживать, какие экземпляры инициализированы, обычно с помощью отдельного индекса или булевого массива. Чтобы извлечь значение, используются assume_init, assume_init_ref или std::ptr::read, но только после доказанного написания валидного T с помощью write или манипуляции с указателями. Критический инвариант заключается в том, что assume_init никогда не должно вызываться на памяти, которая не была полностью инициализирована, и при отказе от частично инициализированной структуры программист должен вручную удалить только инициализированные элементы с помощью ptr::drop_in_place, чтобы избежать утечек ресурсов.
use std::mem::{self, MaybeUninit}; use std::ptr; fn init_array_fallible<T, E, const N: usize>( mut f: impl FnMut(usize) -> Result<T, E>, ) -> Result<[T; N], E> { let mut array: [MaybeUninit<T>; N] = unsafe { MaybeUninit::uninit().assume_init() }; let mut i = 0; while i < N { match f(i) { Ok(val) => { array[i].write(val); i += 1; } Err(e) => { for j in 0..i { unsafe { ptr::drop_in_place(array[j].as_mut_ptr()); } } return Err(e); } } } Ok(unsafe { mem::transmute::<[MaybeUninit<T>; N], [T; N]>(array) }) }
Вы разрабатываете no_std драйвер ядра для сетевой карты, где выделение памяти из кучи запрещено и латентность должна быть детерминирована. Вам нужно выделить массив фиксированного размера из 1024 объектов Connection в стеке. Каждое инициализация Connection включает запись в аппаратный регистр, которая может не удаться, если буфер NIC переполнен. Проблема заключается в том, чтобы гарантировать, что если 500-я связь не удалась, предыдущие 499 были корректно закрыты (освобождая файловые дескрипторы и освобождая DMA-карты), в то время как оставшиеся 524 слота остаются нетронутыми, избегая неопределенного поведения из-за освобождения неинициализированной памяти.
Один из возможных подходов заключается в использовании Default::default() для предварительной инициализации массива значениями-санитарами. Это требует, чтобы Connection реализовал Default, что проблематично, потому что "умолчающее" соединение все равно потребует ресурсов ядра, которые должны быть явно освобождены, что усложняет процесс ошибок. Кроме того, создание 1024 фиктивных соединений только для их перезаписи тратит циклы инициализации и нарушает строгие временные требования драйвера для вывода интерфейса в рабочее состояние.
Вторая стратегия заключается в использовании Vec<Connection> с with_capacity и динамическим добавлением, за которым следует преобразование в фиксированный массив. Это безопасно и идиоматично в коде пользовательского пространства. Однако, Vec требует глобального аллокатора, который недоступен в этом контексте ядра. Это также вводит потенциальные пути паники и фрагментацию памяти, которые неприемлемы в пространстве ядра, а преобразование в массив фиксированного размера требует проверок времени выполнения, которые усложняют логику обработки ошибок.
Третий подход использует MaybeUninit<[Connection; 1024]> для выделения хранения без инициализации. Успешно инициализированные соединения записываются через MaybeUninit::write, и если ошибка возникает на индексе i, мы вручную проходим от 0 до i-1 и вызываем ptr::drop_in_place на каждом инициализированном слоте перед возвратом ошибки. При успешной инициализации мы трансмутируем весь массив в инициализированный тип. Мы выбрали это решение, потому что оно обеспечивает выделение памяти в стеке без затрат с детерминированной производительностью, соответствует ограничению no_std и гарантирует, что очистка ресурсов происходит только для действительно инициализированных объектов. Результатом стал надежный драйвер, который никогда не вызывал неопределенного поведения во время восстановления после частичного сбоя и поддерживал последовательную латентность инициализации на уровне микросекунд.
Почему вызов assume_init на неинициализированном MaybeUninit<T> составляет неопределенное поведение, даже если значение никогда не читается явно после этого?
Многие кандидаты считают, что неопределенное поведение возникает только при физическом доступе к данным, например, при их выводе или ответвлении. Однако система типов Rust сообщает компилятору, что валидный T существует сразу после вызова assume_init. Для типов с оптимизациями ниши (такими как bool, char, Option<&T> или NonNull<T>) компилятор может генерировать код, который инспектирует битовый шаблон, чтобы определить варианты перечисления или валидность. Если память содержит случайные биты (например, 0xFF для bool), эта инспекция вызывает неопределенное поведение в LLVM (загрузка poison или undef). Кроме того, когда область видимости заканчивается, компилятор вставляет glue для дропа для T, который попытается запустить деструкторы на мусорных данных, что приведет к сбоям или уязвимостям в безопасности. Таким образом, assume_init — это контракт, где программист гарантирует валидную инициализацию; нарушение его отравляет состояние компилятора независимо от явных чтений.
Какова разница между использованием MaybeUninit::write и std::ptr::write на указателе, возвращаемом MaybeUninit::as_mut_ptr(), и когда каждый из них подходит?
MaybeUninit::write — это безопасный метод, который берет на себя владение T и записывает его в неинициализированный слот, возвращая изменяемую ссылку на теперь инициализированные данные. Он предпочтителен, когда вы готовы иметь значение и хотите немедленный безопасный доступ. Напротив, std::ptr::write — это небезопасная функция, которая записывает значение по сырому указателю без чтения или удаления старого значения (что критично, поскольку память неинициализирована). Вы должны использовать ptr::write, когда записываете через сырой указатель, полученный от as_mut_ptr(), и необходимо избежать ограничений проверщика заимствований write, или когда реализуете низкоуровневые абстракции, где у вас только сырой указатель. Ключевое различие заключается в том, что write предоставляет гарантии безопасности и отслеживание времени жизни, в то время как ptr::write требует ручной проверки, что назначение является валидным, правильно выровненным и неинициализированным, чтобы избежать нарушений алиасинга или преждевременных дропов.
Как правильно удалить частично инициализированный массив MaybeUninit<T> без утечек ресурсов или вызова неопределенного поведения, и почему порядок операций критичен?
Когда инициализация не удалась на индексе i, вы должны удалить только элементы 0..i. Правильная процедура заключается в том, чтобы пройти от 0 до i-1 и вызвать std::ptr::drop_in_place(array[j].as_mut_ptr()). Это запустит деструктор для T без перемещения значения из обертки MaybeUninit (что оставит слот в состоянии перемещенного, хотя все еще технически неинициализированного). Критично выполнить эту очистку немедленно после сбоя, перед возвратом ошибки, чтобы гарантировать, что стековый фрейм будет аккуратно размотан. Если вы вместо этого попытаетесь использовать mem::forget на массиве или просто вернетесь, обертка MaybeUninit будет удалена (что не приводит к никаких действию), но живые экземпляры T внутри утекут свои ресурсы (например, файловые дескрипторы или память кучи). Напротив, если вы по ошибке удалите элементы i..N, вы вызовете неопределенное поведение, обращаясь с мусорной памятью как к валидным экземплярам T.