Пример (упрощённый) и краткие объяснения.
Пример функции с unsafe:
```rust
// небезопасная функция — оператор unsafe внутри
pub fn write_first_byte(ptr: *mut u8, len: usize) {
unsafe {
// создаём срез из сырого указателя — это unsafe, потому что требует гарантий от вызывающего
let slice = std::slice::from_raw_parts_mut(ptr, len);
// потенциально UB: если len == 0, или ptr неверен/неинициализирован/уже освобождён
slice[0] = 42;
}
}
```
Типичные источники ошибок безопасности и памяти (на примере выше и в целом)
- Дереференция неверного или нулевого указателя (dangling / null pointer) → UB.
- Неправильное выравнивание указателя (unaligned access).
- Выход за пределы буфера (out-of-bounds) при доступе к срезу/массиву.
- Чтение неинициализированной памяти (use of uninitialized memory).
- Use-after-free / двойное освобождение — если память была освобождена, но есть сырой указатель на неё.
- Нарушение правил заимствования: одновременное наличие нескольких мутабельных ссылок (aliasing mutable).
- Состояния гонки при доступе из нескольких потоков (data race) при некорректной синхронизации.
- Неправильный FFI (несовпадение ABI, неверная сигнатура) или небезопасные transmute/приведения, ломающее инварианты типов.
Почему Rust по умолчанию предотвращает эти ошибки
- Система владения (ownership) и RAII обеспечивает однозначного владельца и автоматическое Drop — снижает use-after-free и двойное освобождение.
- Заимствования и borrow checker запрещают одновременные &mut и другие заимствования → предотвращает алиасинг мутабельных ссылок.
- Ссылки (&T, &mut T) в Rust гарантированно не-null, правильно выровнены и указывают на инициализированную память.
- Лайфтаймы (lifetimes) препятствуют созданию висячих ссылок.
- Индексация и создание срезов имеют защитные проверки (bounds checks).
- Типовая система и маркеры Send/Sync препятствуют неконтролируемым гонкам между потоками (нужно явно реализовать unsafe Send/Sync).
- Наличие вспомогательных типов (e.g. MaybeUninit) делает работу с неинициализированной памятью явной и контролируемой.
Когда оправдано применение unsafe
- FFI: вызовы C/других языков, доступ к системным/аппаратным интерфейсам.
- Реализация примитивов низкого уровня: аллокаторы, lock-free структуры, специализированные контейнеры.
- Оптимизация «горячих» участков, где удаление проверок оправдано и доказуемо безопасно.
- Реализация абстракций, которые затем предоставляют безопасный API (инварианты проверяются внутри unsafe-блока).
- Реализация unsafe-трейтов (например, ручная реализация Send/Sync) только если вы можете доказать корректность.
Рекомендации при использовании unsafe
- Минимизировать область unsafe: держать блоки маленькими и локализованными.
- Документировать все предпосылки/инварианты (что гарантирует вызывающий/что проверено внутри).
- Инкапсулировать unsafe за безопасным API.
- Проверять на Miri, AddressSanitizer/UBSan, использовать Clippy и фазы код-ревью.
- Писать тесты, в том числе на мультипоточность, и по возможности формально доказывать инварианты логикой кода.
- Не полагаться на комментарии: явно проверять то, что можно проверить (null/align/len) и фиксировать с ошибкой, если предпосылки нарушены.
Как можно улучшить пример (проверки и документирование):
```rust
/// Безопасная оболочка: функция вернёт Err, если очевидные предпосылки нарушены.
/// Предупреждение: вызовчик всё равно должен гарантировать, что ptr валидна для len байт.
pub fn write_first_byte_checked(ptr: *mut u8, len: usize) -> Result {
if ptr.is_null() { return Err("null pointer"); }
if len == 0 { return Err("length is zero"); }
// выравнивание для u8 всегда корректно, но для других типов нужно проверять.
unsafe {
// safety: мы проверили null и len>0; вызывающий гарантирует, что память валидна и инициализирована
let slice = std::slice::from_raw_parts_mut(ptr, len);
slice[0] = 42;
}
Ok(())
}
```
Кратко: unsafe нужен, когда вы берёте на себя ответственность за инварианты, которые компилятор обычно гарантирует. Делайте это локально, документируйте и проверяйте с помощью инструментов.