👣 Rust Совет

MaybeUninit для ручной сборки структур без лишнего drop

Когда значение собирается по частям в unsafe-коде, FFI, парсере или аллокаторе, главная проблема не в самой инициализации. Главная проблема - что делать, если ошибка произошла посередине.

Например, одно поле структуры уже создано, а второе еще нет. В этот момент нельзя дропать всю структуру целиком: для Rust она еще не является полностью готовым объектом.

Правильный подход - явно помнить, какие поля уже инициализированы, и очищать только их. Для этого используют MaybeUninit, ptr::write, drop_in_place и, когда значение уже полностью готово, assume_init_drop.

MaybeUninit нужен не “чтобы обмануть Rust”, а чтобы аккуратно управлять жизненным циклом там, где компилятор уже не может сделать это за тебя.

Для таких случаев есть MaybeUninit:

use std::mem::MaybeUninit;

struct Buffer {
    data: Vec<u8>,
    meta: String,
}

let mut value = MaybeUninit::<Buffer>::uninit();

unsafe {
    let ptr = value.as_mut_ptr();

    std::ptr::addr_of_mut!((*ptr).data).write(vec![1, 2, 3]);

    // Если дальше случилась ошибка,
    // дропаем только уже инициализированное поле
    std::ptr::addr_of_mut!((*ptr).data).drop_in_place();

    // А всю Buffer не трогаем:
    // meta еще не была создана
}

Более удобный вариант для полностью инициализированного MaybeUninit<T>:

let mut value = MaybeUninit::new(String::from("hello"));

unsafe {
    value.assume_init_drop();
}

MaybeUninit<T> используют не просто для создания значения “без инициализации”. Он нужен, когда ты сам управляешь моментом, в который память становится настоящим T, и сам отвечаешь за корректный drop.

Если структура собирается по частям, компилятор уже не всегда может понять, какие поля реально созданы. Поэтому unsafe-логику лучше держать внутри маленькой функции или типа, а наружу отдавать обычный safe API. Так риск ошибок остается локальным и проверяемым.

#rust #rustlang #programming #unsafeRust

👣 В Rust нашли интересный способ ускорить pretty printer - штуку, которая красиво форматирует код, JSON, Lisp и другие структуры.

Обычно есть два подхода.

Первый - собрать всё дерево документа целиком. Так делают Wadler-style pretty printers. Это выразительно, но в Rust быстро упирается в память, аллокации и указатели.

Второй - стримить вывод по кускам. Так работает Oppen-style подход. Он легче по памяти, но часто принимает локально хорошие решения и не всегда находит глобально лучший layout.

Автор предлагает третий вариант: не хранить документ как рекурсивный enum, а описывать его через trait Doc.

То есть Text, Concat, Group, Nest и другие элементы становятся отдельными типами, которые умеют сами себя рендерить через layout().

Звучит как мелкая архитектурная правка, но эффект большой: меньше лишних аллокаций, меньше прыжков по памяти, гибче управление Box, Rc и другими стратегиями хранения.

В proof-of-concept реализации pye автор получил до 60x ускорения по сравнению с прямой Rust-реализацией алгоритма из paper “A Pretty Expressive Printer”. А в обновлённых тестах вариант с таким дизайном и greedy-алгоритмом местами обгонял pretty и arena-версию больше чем в 10 раз.

В Rust производительность часто ломается не только на алгоритме, но и на форме данных.

Иногда enum выглядит красиво, но trait-based дизайн лучше ложится на память, ownership и реальные оптимизации компилятора.

blog.wybxc.cc/blog/pretty-printer-pye/

#Rust #RustLang #Compilers #OpenSource #SystemsProgramming

👣 Rust без боли начинается не с синтаксиса, а с правильных паттернов

Microsoft выложила практический гайд Rust: Patterns & Engineering How-Tos - не для тех, кто только открыл println!, а для разработчиков, которые уже упёрлись в реальные production-вопросы.

Что внутри:

- type-state и newtype для безопасного дизайна API
- PhantomData для lifetime branding, variance и zero-cost типизации
- channels, actors и concurrency-паттерны
- async pitfalls, где Rust чаще всего ломает ожидания новичков
- error handling через thiserror и anyhow
- тестирование через unit, integration, doc tests и proptest
- benchmarking через criterion

Это особенно полезно для тех, кто приходит из C++, C# или Go и внезапно понимает, что borrow checker - это не главный враг. Главная сложность в Rust - выбрать правильную форму абстракции до того, как код превратится в набор lifetime-костылей.

Если вы уже прошли Rust Book, но всё ещё зависаете на generics, trait bounds, PhantomData, async и тестировании, это очень хороший следующий шаг.

https://microsoft.github.io/RustTraining/rust-patterns-book/

#rust #rustlang

✔️ Фраза «у Rust тоже есть CVE» часто звучит как аргумент против memory safety.

Но тут есть важная разница.

В C, если вы вызвали функцию не так, например передали NULL туда, где библиотека этого не ждала, и получили segfault, это часто называют неправильным использованием API.

То есть ответственность перекладывается на разработчика: сам виноват, надо было читать документацию.

В Rust логика другая.

Если функция помечена как safe, она не должна приводить к memory bugs. Даже если вы передали странные данные, даже если сценарий неидеальный. Safe Rust по контракту обязан оставаться memory-safe.

Поэтому если safe-функция в Rust падает с segfault или приводит к проблеме памяти, это уже не «ты неправильно использовал API». Это баг библиотеки. И такой случай действительно может стать CVE.

Сырые числа CVE у Rust и C/C++ нельзя сравнивать напрямую.

В C/C++ огромный класс проблем считается нормальным риском неправильного использования. В Rust тот же класс проблем считается нарушением гарантий safe API.

Именно поэтому CVE в Rust часто говорит не «Rust такой же небезопасный», а наоборот: экосистема строже относится к тому, что safe-код вообще не должен ломать память.

Хороший разбор от Jakub Beránek из команды разрабов компилятора Rust:

http://kobzol.github.io/rust/2026/06/15/how-memory-safety-cves-differ-between-rust-and-c-cpp.html

#Rust #RustLang #MemorySafety #Security #CVE